220717 WIL (JWT, API) #1
항해99의 첫 미니프로젝트를 진행하면서 느낀점과 프로젝트 내에서 사용했던 JWT와 API를 사용하면서 느낌점을 적어보았다.
-
느낀점
-
JWT
4일이라는 짧은시간동안 강의를 보며 프로젝트를 진행하였는데 JWT강의를 보아도 머릿속에 들어오지 않았다.
로그인과 회원가입이 내가해야할 파트가 아니라 집중이 덜했을지도 모르지만, 강의를 보면서 내가 이것을 어떻게 적용할것인가를 생각하지 않고 강의를 봐서 이런 결과를 낳았다고 생각한다.
다음부터는 프로젝트의 전체 흐름을 먼저 생각해보고 필요한부분을 먼저 노트를 해놓고 강의를 보면 더 좋은 결과가 나올것 같다.
기본적인 틀은 request.cookies.get('mytoken') mytoken에서 쿠키를 받아와서
jwt.decode(token_receive, SECRET_KEY, algorithms=['HS256']) 받아온것과 저장해놓은 SECRET_KEY와 알고리즘을 사용해서 드코드하여 원하는 정보를 뽑아왔다.
받아온 닉네임을 이용해 게시글이 이용자의 ID와 같다면 수정이나 삭제가 가능하도록 해놨는데, 시간이 부족해 닉네임만 일치하면 가능하도록 할 수 밖에 없었다. 닉네임을 통해 id값을 받아오고 작성자의 id와 일치하면 삭제를 하던가, 닉네임이 중복이 안되게 했으면 더 좋았을 것 같다.
- API
서버와 통신하는데 ajax를 사용했다. ajax는 사전강의에서 배운것을 바탕으로 어렵지는 않았으나, jinja를 사용해서 다른 방법대로 할려고 하니 약간의 어려움이 있었다.
버튼을 누를때마다 해당 게시글의 정보가 넘어가게 만들기를 원했는데 정보를 뽑아 특정 url에 그 정보를 보내는것이 쉽지 않았다.
3번 게시글을 눌렀을때 게시글에 저장된 정보가 url/3과 비슷한 곳에 정보를 보내야했는데 이를 적용하는게 어려웠다.
그리하여 게시글을 눌렀을때 게시글에 작성된 정보를 사용하는것이 아닌 서버에서 다시 정보를 받아와서 페이지를 만들었다.
게시글로부터 정보를 주었다면 더 간략화되고 시간도 줄였을것 같은데 아쉬운 부분이다.
또한 만들고나서 제출하기 직전에 보니
지금까지 사용했던 다른 사이트에서 당연하게 사용했던 기능들이 이번 프로젝트에서는 적용이 안된것이 보였다. 그렇게 어렵지도 않은 기능들이었고, 조금만 더 신경을 썼으면 좋았을텐데라는 아쉬움이 남는 프로젝트였다. 다음부터는 프로젝트를 스스로 이용하는 시간을 좀 가져서 무엇을 더 넣을까보다는 무엇이 빠졌을지에 대해 생각하는 시간도 필요할 것 같다.
JWT
JWT(JSON Web Token): 인증에 필요한 정보를 암호화시킨 JSON 토큰
JWT토큰을 HTTP헤더에 실어 서버가 클라이언트를 식별하게 된다
JWT는 .을 기준으로 나누어지며 세가지 문자열로 구성되어있다.
AAAAA.BBBBB.CCCCC
A: Header = { "alg":"H1234", "typ":"JWT"}
( alg: 서명 암호화 알고리즘, typ: 토큰의 유형 )
B: Payload = { "sub": "1234561234", "name": "donghwan", "iat": 44322212 }
( payload에는 토큰에서 사용할 정보의 조각들이 담겨있다. 서버와 클라이언트가 주고받을 정보를 갖고있다.
payload에는 정해진 타입은 없지만, Registered claims, Public claims, Private claims 세 가지로 나뉜다.)
C: Signature = { HMACSHA256(base64UrlENcode(header)+"."+base64UrlEncode(payload),your-256-bit-secret }
( 시그니처에서 사용하는 알고리즘은 헤더에 정의한 방식을 사용한다. Header, Payload를 Base64 URL -safe Encode를 한 이후 Header에 명시된 해시함수를 적용하고, 개인키로 서명한 전자서명이 담겨있다. )
전자서명에는 비대칭 암호화 알고리즘을 사용하므로 암호화를 위한 키와 복호화를 위한 키가 다르다.
- 사용자 > 서버: 사용자가 ID와 PW로 로그인
- 사용자 < 서버: header, payload, signature를 정의, 각각 Base64로 한번 더 암호화하여 JWT를 생성, 쿠키에 담에 발급
- 사용자 > 서버: JWT를 로컬 스토리지에 저장, API를 요청, 이때 Authorization header에 Access Token을 담아서 보낸다.
- 사용자 < 서버: 액세스 토큰에 문제가 없으면 정보에 응답
- 사용자 > 서버: 리프래시 토큰으로 액세스 토큰 재발급
- 사용자 < 서버: 액세스 토큰 재발급
JWT는 서명이 목적이다.
JWT는 Base64로 암호화를 하기 때문에 디버거를 사용해서 인코딩된 JWT를 복호화할수 있다.
복호화를 하게되면 데이터를 담은 payload가 노출되어버리기 때문에 payload에는 비밀번호와 같은 민감한 정보는 넣지 말아야 한다.
JWT의 장점
- header와 payload를 가지고 signature를 생성하기 때문에 데이터 위변조를 막을수 있다.
- 인증 정보에 대한 별도의 저장소가 필요없다.
- JWT는 토큰에 대한 기본 정보와 전달한 정보 및 토큰이 검증됬음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
- 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태가 된다.
- 확장성이 우수하다.
- 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.
- OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
- 모바일 어플리케이션 환경에서도 잘 작동한다.
JWT의 단점
- 쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
- payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
- 토큰을 탈취당하면 대처하기 어렵다.
API
API(Application Programming Interface)는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 말한다.
인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있다.
이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의합니다.
API 문서에는 개발자가 이러한 요청과 응답을 구성하는 방법에 대한 정보가 들어 있습니다.
API의 종류에는 SOAP API, RPC API, Websocket API, REST API가 있다.
그중에서도 오늘은 가장 많이사용되고 유연한 REST API를 중점으로 알아보려고 한다.
REST(Representational State Transfar) 클라이언트가 서버 데이터를 액세스하는데 사용할 수 있는 GET, PUT, DELETE 등의 함수집합을 정의
클라이언트와 서버는 HTTP를 사용해서 데이터를 교환한다.
REST API의 주된 특징은 무상태이다.
(무상태: 무상태는 서버가 요청 간에 클라이언트 데이터를 저장하지 않음)
REST API의 장점
- 통합
API는 새로운 애플리케이션을 기존 소프트웨어 시스템과 통합하는 데 사용됩니다. 그러면 각 기능을 처음부터 작성할 필요가 없기 때문에 개발 속도가 빨라집니다. API를 사용하여 기존 코드를 활용할 수 있습니다.
- 확장
API는 기업이 다양한 플랫폼에서 고객의 요구 사항을 충족할 수 있는 고유한 기회를 제공합니다. 예를 들어 지도 API를 사용하면 웹 사이트, Android, iOS 등을 통해 지도 정보를 통합할 수 있습니다.
- 유지 관리의 용이성
API는 두 시스템 간의 게이트웨이 역할을 합니다. API가 영향을 받지 않도록 각 시스템은 내부적으로 변경해야 합니다. 이렇게 하면 한 시스템의 향후 코드 변경이 다른 시스템에 영향을 미치지 않습니다
REST API의 보호
- 인증 토큰
인증 토큰은 사용자에게 API 호출을 수행할 수 있는 권한을 부여하는 데 사용됩니다. 인증 토큰은 사용자가 자신이 누구인지 확인하고 해당 특정 API 호출에 대한 액세스 권한이 있는지 확인합니다.
- API 키
API 키는 API를 호출하는 프로그램 또는 애플리케이션을 확인합니다.즉, 애플리케이션을 식별하고 애플리케이션에 특정 API 호출을 수행하는 데 필요한 액세스 권한이 있는지 확인합니다. API 키는 토큰만큼 안전하지 않지만 사용량에 대한 데이터를 수집하기 위해 API 모니터링을 허용합니다.
