1. 개념
•
인증은 토큰기반 인증 서버를 통해서 처리하고, 다른 컨텐츠를 주는 서버는 stateless 하게 하자는 이론이 담겨있다.
•
여기서 토큰은 주로 JWT 토큰이 사용된다.
2. 과정
1.
클라이언트는 로그인 정보를 인증서버로 보낸다.
2.
인증서버에서는 클라이언트의 정보를 확인한 뒤, 토큰을 생성하여 전달한다.
a.
토큰에는 accessToken, refreshToken 두 가지가 존재한다.
3.
받은 토큰을 헤더값에 넣어 클라이언트는 다른 서버들에게 stateless 하게 요청한다.
3. JWT
•
Json Web Token 을 의미하며, json 객체로 인코딩되어 다음과 같은 이름이 붙었다.
•
헤더, 페이로드, 서명 등 세 개의 파트로 구성되어있다.
◦
header : 어떠한 서명 알고리즘을 사용할 것인지에 대한 정보
◦
payload : 데이터, 토큰 발급자, 토큰 만료기간(유효기간),
◦
signature : 헤더에 정의된 알고리즘으로 인코딩된 헤더값, 인코딩된 payload 값, 그리고 비밀키를 기반으로 생성된 서명값이다.
•
메시지 인증이나 암호화에 사용된다.
•
실습해보기
4. 장점과 단점
•
장점
◦
사용자 인증에 필요한 값은 토큰에 담겨있으므로, 별도의 인증 저장소가 필요없다.
◦
다른 종류의 토큰 SAML(Security Assersion Markup Language Tokens) 과 비교해 보았을 때 경량화되어있다.
◦
Json object 타입으로 인코딩 되어있기 때문에 직렬화, 역직렬화가 용이하다.
•
단점
◦
토큰이 탈취당했을 경우, 디코딩하여 데이터를 볼 수 있다.
◦
토큰의 양이 커지면 서버에 과부하를 줄 수 있다.
5. 구현해보기
•
token 기반 인증방식은 2가지 토큰을 이용하여 이루어진다고 했다.
•
클라이언트에서 서버로 로그인 정보를 보내면 서버는 accessToken, refreshToken 두 가지를 응답한다.
•
바로 이 refreshToken 을 이용하여 accessToken 이 만료되기 전에 새로운 accessToken 값이 전달된다.
•
따라서 보통 accessToken 은 유효 기간이 짧고, refreshToken 은 그것보다 조금 길다.
6. 주의할 점
OAuth2.0 과 JWT 에 관한 표준문서인 RFC 6750, RFC 7519 를 기반으로 보면, 아래와 같은 점들을 주의해야한다.
{% embed url=“https://www.rfc-editor.org/rfc/rfc6750” %}
1.
토큰값은 주로 Http Header 의 Authorization 혹은 Http Header 의 Cookie 에 담겨 요청되는데, 이때, value 값에는 “Bearer” 를 토큰 맨 앞에 붙여주어, 현재 토큰 기반으로 인증을 하고 있다는 것을 알려주어야 한다.
2.
Https 를 사용해야한다.
3.
쿠키에 저장한다면, SameSite:Strict 설정을 추가해야한다.
4.
토큰은 수명이 짧게 두어 보안을 높이는 것이 좋다.
5.
url 에 토큰을 전달해서는 안된다.