로그인 #2. 토큰기반인증방식(access토큰, refresh토큰): 개념
토큰기반은 유저의 상태를 토큰에 담아놓고 서버들은 stateless하게 가자라는 이론이 담긴 기법임
이 토큰에다가 유저의 상태값을 다 넣음
이걸 기반으로 유저가 유효한지아닌지를 확인
어떻게 구현하냐면
MSA기반으로 설명
장바구니, 결제 서버가 있다
토큰을 관리하는 서버도 한대 존재
나머지 서버들은 토큰에대한 어떤 로직도 없음
보통은 이렇게함
근데 토큰 서버를 따로 두지 않고 다른 도메인을 처리하는 서버에 합쳐서 구축할 경우에
그 도메인에서 에러가 발생할 경우 인증에 관한 기능이 마비가 되고 이는 다른 도메인의 기능이 연쇄적으로 마비가 될 가능성이 있다.
토큰이 어떻게 생성되는가
1. 유저가 올바른 패스워드를 입력하면 토큰을 관리하는 authorization server에서 토큰을 줌
2. 그 토큰을 기반으로 사용자가 요청을 할 때 access토큰을 http header-authorization 또는 http header-cookie에 담아 인증이 필요한 서버에 요청해 원하는 컨텐츠를 가져옴
JWT란?
- JWT는 JSON Web Token을 의미하며 헤더, 페이로드, 서명으로 이루어져 있으며 JSON 객체로 인코딩되며 메시지 인증, 암호화에 사용된다.
Header: 토큰 유형과 서명 알고리즘, base64URI로 인코딩됨
Payload: 데이터, 토큰 발급자, 토큰 유효기간, base64URI로 인코딩됨
Signature: (인코딩된 header + payload) + 비밀키를 기반으로 헤더에 명시된 알고리즘으로 다시 생성한 서명값
JWT 장점
- 사용자 인증에 필요한 모든 정보가 토큰 자체에 포함되어있기 때문에 별도의 인증 저장소가 필요 없다.
- 다른 유형의 토큰과 비교했을 때 경량화 되어있다.
- 디코딩했을 때 JSON이 나오기 때문에 JSON을 기반으로 쉽게 직렬화, 역직렬화가 가능하다.
JWT 단점
- 토큰이 비대해질 경우 당연히 서버 과부화에 영향을 줄 수 있다.
- 토큰을 탈취당했을 경우 디코딩했을 때 데이터를 볼 수 있다. -> 가장 신경써야하는 단점
토큰기반인증방식을 구현할 땐 refresh토큰과 access토큰 두 개를 기반으로 구현한다.
access토큰의 수명은 짧게 - 헤더에
refresh토큰의 수명은 길게 - 데이터베이스나 Redis에 저장
refresh토큰이란?
- access토큰이 만료되었을 때 다시 access토큰을 얻기 위해 사용되는 토큰.
이를 통해 access토큰이 만료되었을 때마다 인증에 관한 비용이 줄어들게 된다.
로그인을 하게 되면 access토큰과 refresh토큰 두개를 얻는다.
그 다음 access토큰이 만료되거나 사용자가 새로고침을 할 때 refresh토큰을 기반으로 새로운 access토큰을 얻는다.
access 토큰 -> 인증을 위한 토큰
해커가 이걸 탈취하면 안되니까 만료기한을 작게 해야함
만료기한이 작으면 로그인을 여러번 해야한다는 단점이 생기잖아
서비스 이용하기 싫어짐
이걸 해결하기위해 refresh 토큰과 같이 씀
refresh 토큰은 만료기한이 큼. 이걸 기반으로 access토큰을 발급 받음
이렇게 하면 토큰기반인증방식의 장점을 취하면서 access토큰의 만료기한이 줄어드는것까지 보완하는 방식이 된다.
주의해야할 점
- access토큰을 얻었다면 그 이후에 요청을 할 때는 HTTP header-Authorization 또는 HTTP Header-Cookie에 담아 요청을 하게 된다. 이때 다음과 같은 규칙을 지키는 것이 좋다.
- Bearer <토큰>으로 Bearer을 앞에 둬서 토큰기반인증방식이라는 것을 알려주어야 한다.
- https를 사용해야 한다.
- 쿠키에 저장한다면 sameSite: 'Strict'을 써야한다.
- 수명이 짧은 access token을 발급해야 한다.
- url에 토큰을 전달하지 말아야 한다.
** 이러한 점들은 OAuth2.0과 JWT에 관한 표준문서인 RFC6750, RFC7519를 기반으로 설명함
