사용자가 서비스를 이용할 때, 권한이 필요한 모든 요청마다 사용자에게 인증(로그인)을 요구할 수는 없다.
사용자의 경험성을 향상하기 위해 사용자의 인증 정보를 관리할 방법이 필요하다.
이 때 Session과 Access Token은 로그인에 가장 자주 이용되는 방식이다.
Session
사용자가 로그인을 거치면 애플리케이션은 세션을 생성한다.
생성된 세션을 서버측에선 메모리에 저장하고, 사용자에게 세션 ID를 전달하고 브라우저의 쿠키에서 관리된다.
인증 과정
- 최초 로그인시 서버는 세션을 생성하여 메모리에 저장한다.
- 생성한 세션의 sessionID를 사용자에게 전달하고, 이는 브라우져의 쿠키에 저장된다.
- 이후 사용자의 요청은 쿠키와 함께 전달되며, 서버에서는 쿠키에 담긴 sessionID를 확인한다.
- 서버는 sessionID를 통해 메모리의 세션 저장소를 탐색하여 세션 정보를 얻은 뒤, 사용자가 해당 요청에 대한 권한이 있는지 확인하여 응답을 반환한다.
- 세션에는 유효기간(TTL)이 존재하며, 만료시 서버는 재로그인을 요청한다.
장점
- 세션의 유효기간 동안 사용자는 로그인을 하지 않아도 되며, 사용자 경험이 향상된다.
- 세션 정보는 상대적으로 보안이 취약한 쿠키가 아닌 서버에 저장된다.
단점
- 세션 ID가 탈취될 경우 사용자의 인증 정보가 노출된다.
- 매 요청마다 서버는 세션 정보를 확인해야 하며, 이에 따른 오버로드가 발생한다.
- 사용자의 수가 많아질수록 세션을 저장하기 위한 메모리 사용량이 증가한다.
- 인증이 서버에 의존적이기 때문에 확장성이 약하다.
- 서버1에 저장된 세션의 경우, 서버2를 통한 인증을 실패한다.
개선 방안
- HTTPS 통신을 이용한다.
- 세션 저장소에 Redis를 이용한다.(scale out)
Access Token(JWT)
사용자가 로그인을 거치면 애플리케이션은 액세스 토큰을 발급한다.
일반적으로 액세스 토큰에는 JWT가 이용되며, 사용자의 인증 정보를 포함한다.
액세스 토큰의 정보는 서버에 저장되지 않으며, 서버 입장에서 stateless 하다.
JWT(Json Web Token)
Json 형태로 인코딩된 토큰으로, Header, Payload, Signature로 구성되어 있다.
1. Header
토큰의 타입과 암호화 알고리즘 정보를 포함한다.
2. Payload
사용자의 ID, 권한 등의 정보가 포함된다.
3. Signature
Header와 Payload를 이용하여 HMACSHA256를 이용하여 서명된 값이다.
서버측에서 이 시그니처를 private key로 복호화하여 요청이 유효한지 확인한다.
인증 과정
- 최초 로그인시 서버는 JWT 토큰을 생성하여 브라우저를 통해 사용자에게 전달한다.
- 이후 사용자의 요청은 헤더에 JWT 토큰을 포함하여 서버에게 전달된다.
- 서버는 전달받은 JWT의 시그니처를 복호화하여 요청의 유효성을 확인한다.
- 액세스 토큰에는 유효기간(TTL)이 존재하며, 만료시 서버는 재로그인을 요청한다.
장점
- 세션과 다르게 stateless 하기 때문에 서버의 부하가 적다.
- 인증이 서버에 의존적이지 않기 때문에 확장성에 강하다.
단점
- JWT의 Payload는 암호화되어있지 않으며, 이 부분에 민감한 사용자의 데이터를 담을 수 없다.
- 액세스 토큰을 탈취당한 경우 해당 토큰의 권한을 악용할 수 있다.
Refresh Token
리프레시 토큰이란 액세스 토큰 발급을 위해 이용되는 토큰이다.
리프레시 토큰이 이용되는 이유는 다음과 같다.
액세스 토큰이 탈취된 경우, 공격자는 해당 토큰의 권한을 자유롭게 이용할 수 있다.
액세스 토큰은 서버에 stateless 하기 때문에 해당 토큰을 즉각적으로 무효화 할 수 없다.
따라서 보안을 위해 액세스 토큰의 유효기간을 짧게 두는 것이 권장된다.
하지만 액세스 토큰의 유효기간이 짧아진 경우, 사용자에게 재로그인 요청이 잦아질 것이고 사용자의 경험성이 저하된다.
이를 해결하기 위해 이용되는 방법이 Refresh Token이다.
액세스 토큰의 유효기간을 짧게 두고, 액세스 토큰의 재발급에 이용되는 리프레시 토큰을 발급한다.
일반적으로 액세스 토큰의 유효기간은 5분에서 1시간 이내, 리프레시 토큰은 1일 ~ 1달 이다.
유효기간이 짧은 액세스 토큰이 만료된 경우 리프레시 토큰으로 액세스 토큰을 재발급 받아 요청을 재시도한다.
이 때 재로그인이 아닌 리프레시 토큰을 이용한 액세스 토큰 재발급을 수행하기 때문에 사용자는 재로그인을 하지 않아도 되며, 사용자의 경험성이 보장된다.
리프레시 토큰은 브라우저의 쿠키에 저장되며, 보안을 위해 Http Only 또는 Secured 설정이 권장된다.
인증 과정
- 로그인시 사용자에게 Access Token과 Refresh Token을 발급한다.
- 발급받은 액세스 토큰의 유효기간 동안 토큰을 이용하여 요청을 진행한다.
- 토큰이 만료된 경우 서버는 리프레시 토큰을 요구한다.
- 브라우저에 저장된 리프레시 토큰을 서버에게 전송하여 액세스 토큰을 재발급 받는다.
- 리프레시 토큰이 만료된 경우, 서버는 재로그인을 요청한다.
