로그인은 세션기반과 토큰기반의 인증방식이 있다.
세션기반 인증방식
HTTP의 특징 중 하나는 상태없음(stateless) 하다라는 것인데
즉, HTTP 요청을 통해 데이터를 주고 받을 때 요청이 끝나면 요청한 사용자의 정보 등을 유지하지 않는 특징이 있다. (이전부터 CS 공부하면서 아는 내용)
그럼 로그인 상태는 어떻게 유지하는걸까?
- 세션 : 서버와 클라이언트의 연결이 활성화된 상태를 의미합니다.
- 세션ID : 웹 서버 또는 DB에 저장되는 클라이언트에 대한 유니크한 ID
세션기반 로그인 과정
- 처음 로그인 >> 세션ID가 생성됨 >> 서버에서 세션ID를 쿠키로 설정해서 클라이언트에 전달
- 클라이언트가 서버에 요청을 보낼 때 해당 세션ID를 쿠키로 담아서 전에 로그인했던 아이디인지 확인
- 로그인을 유지
다른 페이지를 넘어가더라도 쿠키에 있는 세션ID를 보고 해당 ID가 이미 유효하기 때문에 로그인 상태가 유지되는 것이다.
단점
- 사용자의 상태에 관한 데이터를 서버에 저장했을 때 로그인 중인 유저의 수가 늘어난다면?
- 서버의 메모리 과부화가 일어날 수 있다.
- DB 중 RDBMS에 저장한다면, 직렬화 및 역직렬화에 관한 오버헤드가 발생
MySQL 같은 곳에 저장한다면 (아마 VARCHAR 형태로 저장될 것)
이 때 직렬화와 역직렬화에 대한 단점을 굳이 꼽아볼 수 있다.
토큰기반 인증방식
acceess 토큰, refresh 토큰, JWT 토큰에 대해서는 들어봤을 것이다.
토큰기반 인증방식에 대해 알아보자.
토큰기반 인증방식은 state를 모두 토큰 자체만으로 처리하며 토큰을 처리하는 한 서버를 두고 다른 컨텐츠를 제공하는 서버는 모두 stateless하게 만들자는 이론이 담긴 방식이다.
왜 토큰을 관리하는 서버는 따로 두어야 할까?
이는 여러 개의 서버를 운용한다라고 했을 때
- 토큰기반 인증 + A도메인을 처리하는 서버로
구축할 경우
A도메인에서 에러가 발생이 되면, 인증에 관한 기능이 마비되고 이는 B, C, D 등의 도메인 기능이 연쇄적으로 마비될 수 있기 때문이다.
토큰은 주로 JWT 토큰이 활용된다.
1. 인증로직 >> JWT 토큰 생성(access 토큰, refresh 토큰)
2. 사용자가 이후에 access 토큰을 HTTP Header - Authorization 또는 HTTP Header
Cookie에 담아 인증이 필요한 서버에 요청해 원하는 컨텐츠를 가져온다.
JWT
JWT는 JSON Web Token을 의미하며 헤더, 페이로드, 서명으로 이루어져 있으며 JSON 객체로 인코딩되며 메시지 인증, 암호화에 사용됩니다.
Header
- 토큰 유형과 서명 알고리즘, base64URI로 인코딩 됩니다.
Payload
- 데이터, 토큰 발급자, 토큰 유효기간, base64URI로 인코딩 됩니다.
Signature
- (인코딩된 header + payload) + 비밀키를 기반으로 헤더에 명시된 알고리즘으로 다시
생성한 서명값.
여기로 가서 보면 Header랑 Payload 를 base64UrlEncode 하고 
비밀키 기반으로 서명 알고리즘을 통해 만들어진다. 그것을 왼쪽에서 확인 가능할 것이다.
장점
- 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증저장소가 필요 X
- 다른 유형의 토큰과 비교했을 때 경량화되어있습니다. SAML(Security Assertion Markup Language Tokens)이란 토큰이 있지만 이에 비해 훨씬 경량화되어 있음.
- 디코딩했을 때 JSON이 나오기 때문에 JSON을 기반으로 쉽게 직렬화, 역직렬화가
가능하다.
단점
- 토큰이 비대해질 경우 당연히 서버과부화에 영향을 줄 수 있다.
- 토큰을 탈취당할 경우 디코딩했을 때 데이터를 볼 수 있다.
Access 토큰, Refresh 토큰
access토큰의 수명은 짧게, refresh토큰의 수명은 길게 한다.
refresh토큰은 access토큰이 만료되었을 때 다시 access 토큰을 얻기 위해 사용되는
토큰이다.
이를 통해 access토큰이 만료될 때마다 인증에 관한 비용이 줄어들게 된다.
로그인을 하게 되면 access 토큰과 refresh 토큰 두개를 얻는데
access 토큰이 만료되거나 사용자가 새로고침을 할 때 refresh 토큰을 기반으로 새로운 access token을 얻는다.
왜 나눠서 할까?
access 토큰 : 인증용 토큰이다.
해커가 access 토큰을 탈취해 로그인한다면? -> 안 되기 때문에 만료기한을 적게 해야 한다.
만료기한이 지나면 이후에는 사용 못하기 때문에 해커도 탈취해서 사용하기 힘들다.
refresh 토큰 : 갱신용 토큰
access 토큰이 짧은 만큼 refresh 토큰은 갱신 기간을 둬서 갱신 가능하게끔 해주는 것이다.
주의할 점
이렇게 access토큰을 얻었다면 그 이후에 요청을 할 때는 HTTP Header - Authorization 또는 HTTP Header - Cookie에 담아 요청을 하게 되는데 이 때 다음과 같은 규칙을
지키는 것이 좋다.
Bearer <token>으로"Bearer " (띄어쓰기 포함)을 앞에 둬서 토큰기반인증방식이라는 것을 알려줘야 한다.https를 사용해야 한다.- 쿠키에 저장한다면
sameSite: 'Strict'을 써야 한다. - 수명이 짧은
access token을 발급해야 한다. - url에 토큰을 전달하지 말아야 한다.
토큰을 탈취당하는 것을 대비하는 방법
- 먼저 Access Token의 수명을 짧게 설정하여 탈취된 토큰의 유효 기간을 최소화. 짧은 수명의 Access Token을 사용하고, 필요할 때만 Refresh Token을 통해 새로운 Access Token을 발급
- Refresh Token을 사용하여 민감한 작업을 수행하려고 할 때 추가적인 사용자 인증
단계를 요구한다.
- 예를 들어, IP주소, 디바이스 정보등을 이용하거나 google authentifactor를 이용한 2단계 인증을 사용한다.
- 쿠키에 HttpOnly 및 Secure 을 걸어서 관리
