목차
- 토큰 기반 인증 필요성
- 토큰과 토큰 기반 인증이란?
- 토큰 기반 인증 과정
- 세션 인증 방식과 토큰 인증 방식 차이
- JWT란?
- JWT 사용 시 주의사항
- 엑세스 토큰과 리프레 토큰
1. 토큰 기반 인증 필요성
웹에서 쿠키와 세션을 이용해 클라이언트와 서버 사이의 상태 정보를 저장하는데, 상태 정보를 이용하여 동작하는 가장 흔한 기능은 단연코 '인증과 인가'이다. 로그인에 성공한 사용자가 사이트를 이용하기 위해 권한을 부여받은 것을 '인가', 신원을 증명하는 행위를 '인증'라고 한다.
쿠키는 클라이언트에 데이터를 저장하기 때문에, 탈취와 변조에 대한 위험성을 지닌다. 따라서 인증과 인가를 위해 사용하기보다 팝업 창에서 오늘 하루 그만 보기, 장바구니 등과 같은 기능에 사용된다. 세션은 데이터베이스를 이용해 서버에 저장되며, 서버가 세션 정보를 관리할 수 있다. 따라서 인증과 인가를 위한 기능으로 사용된다.
하지만 매번 요청이 들어올 때마다 세션 ID를 확인해주어야 한다. 이러한 방식은 요청이 많아질수록 더 많은 부하를 발생시키고, 여러 개의 서버로 나뉘어 있을 때 이전에 로그인한 서버가 아닐 경우에는 확인이 어렵다는 단점이 있다. 이를 보완하기 위해 토큰 기반 인증 방식을 사용한다.
세션은 데이터베이스에 저장된 세션 ID와 일치해야 하는지 확인하는 과정을 거치지만, 토큰은 서버가 가진 비밀키로 복호화해 얻은 엑세스 토큰이 유효한지 확인하는 과정을 거치므로 세션처럼 데이터베이스에 접근할 필요가 없다. 또한 토큰의 payload에는 토큰 발급자, 토큰 만료시간, 권한 레벨 등이 들어있기 때문에 데이터베이스에 찾아야 할 정보가 줄어든다.
2. 토큰과 토큰 기반 인증 방식이란?
토큰은 클라이언트의 인증 정보와 권한 정보를 가지고 있는 데이터이다. 토큰은 비밀키를 이용해 토큰이 위조되었는지 확인하고, 토큰에 담긴 데이터를 가져올 수 있다. 토큰 기반 인증은 클라이언트가 서버에 데이터를 요청할 때마다 토큰의 만료 시간 등을 확인하여 토큰에 대한 검증이 이뤄진다.
(특징)
- Stateless와 Scalability
토큰 기반 인증 방식은 서버에 클라이언트 정보를 저장해두지 않는다. 즉, 무상태성 혹은 Stateless하다는 의미이다. 토큰을 이용해 사용자인지 확인하고 권한에 따라 정보를 제공하기 때문에, 클라이언트와 서버의 연결고리가 존재하지 않는다.
서버가 여러 대 존재할 때 세션 인증 방식을 생각해보면, 각 서버에 저장된 세션 ID가 다르기 때문에 이전에 특정 서버에서 인증을 받은 클라이언트는 추후에 요청도 동일한 서버에 접속해야 한다. 하지만 토큰은 이전에 요청한 서버로 다시 요청할 필요가 없다. 그 이유는 서버에 클라이언트 정보를 저장하지 않는 Stateless한 특성 때문이며, 결과적으로 분산 처리를 위한 서버 확장성(Scability)이 높아진다. - Extensibility
토큰을 사용해 다른 서비스에도 인가를 부여할 수 있다. 대표적인 예시로 Oauth가 있다. 웹서비스에 새롭게 회원가입하는 대신, Google, Naver, KaKao 계정으로 로그인함으로써 권한을 부여받을 수 있는 것이다.
(장점)
- 토큰을 위한 별도의 저장소가 필요 없음
- 메모리 부하가 적음
- 서버 확장성이 좋음
(단점)
- 토큰은 탈취 시에 강제로 끊을 수 없음 (세션은 탈취 시에 데이터베이스의 세션 ID 삭제 등으로 관리할 수 있음)
- 토큰 payload에 정보를 담기 때문에 토큰의 크기가 커지면서 네트워크 부하가 발생할 수 있음
3. 토큰 기반 인증 과정
1) 클라이언트가 아이디와 비밀번호를 담아 로그인 요청
2) 서버가 계정 정보 확인
3) 계정 정보가 일치하면, 서버는 클라이언트에게 토큰을 발급해 전달
4) 클라이언트는 받은 토큰을 로컬 스토리지에 저장해두고, 요청 시에 HTTP 헤더에 토큰을 담아 전달
4) 요청이 들어오면, 서버는 비밀키로 토큰을 복호화하고 검증하여 클라이언트에게 응답 데이터를 반환
4. 세션 인증 방식과 토큰 인증 방식 차이
| 세션 인증 방식 | 토큰 인증 방식 | |
| 저장 위치 | 서버 | 클라이언트 |
| 저장소 | 세션 ID를 관리할 데이터베이스 필요 | 데이터베이스 불필요 |
| 특징 | stateful | stateless |
| 장점 | 탈취 시 세션 ID 삭제로 관리에 용이 | 서버 확장 용이 |
| 단점 | 분산 처리 서버에서 한계를 가짐 | 토큰 관리 불가능 |
5. JWT란?
JWT는 Json Web Token의 약자로, 서버와 클라이언트 사이의 상태 정보를 JSON 포맷의 토큰에 담아 인증 및 인가를 위해 사용된다. 토큰의 payload에 인증 및 인가에 대한 정보 등을 모두 담고 있어 자가수용적(self-contained)인 방식이다.
JWT는 아래와 같이 Header, Payload, Signature의 세 부분으로 이뤄져 있으며, 각 부분은 점(.)을 이용해 구분된다. JSON 형태를 가지고 Base64로 인코딩되며, HTTP 헤더에 포함되어 전달된다.
1) 헤더 (Header)
{
"alg": "HS256",
"typ": "JWT"
}
- alg : Signature를 해싱하기 위한 알고리즘 지정 (ex. SHA256, RSA 등)
- typ : 토큰 타입 (ex. JWT 등)
2) 페이로드 (Payload)
{
"iss": "asdfasdf",
"exp": "1485270000000"
}
- sub : 인증 제목
- iss : 토큰 발급자
- iat : 토큰 발급 시간
- exp : 토큰 만료 시간
3) 서명 (Signature)
서명은 토큰을 인코딩하거나 유효성을 검증할 때 사용하는 고유한 암호화코드이다. 헤더와 페이로드를 각각 Base64로 인코딩해 그 값을 비밀키를 이용해 헤더에서 정의한 알고리즘으로 해싱한다. 그 후, 값을 다시 Base64로 인코딩하여 생성한다.
6. JWT 사용 시 주의사항
페이로드 자체는 암호화된 것이 아닌 BASE64로 인코딩된 것이다. 따라서 누구나 페이로드를 디코딩하여 볼 수 있으므로, 페이로드에는 중요한 데이터를 담아선 안된다.
7. 엑세스 토큰과 리프레시 토큰
지금까지 토큰 기반 인증 방식을 설명하면서 인증 및 인가를 위해 사용했는 토큰을 엑세스 토큰이라고 부른다. 엑세스 토큰은 일반적으로 클라이언트의 권한을 확인하는 용도로 사용된다. 그럼 리프레시 토큰은 왜 필요할까? 그 이유는 엑세스 토큰이 언제든 탈취당할 수 있다고 가정하기 때문이다.
엑세스 토큰이 탈취된다면, 토큰이 만료되기 전까지 누구나 토큰을 사용하고 권한을 가질 수 있다. 따라서 엑세스 토큰을 짧게 설정하고, 엑세스 토큰이 만료될 때마다 리프래시 토큰을 확인해 새로운 엑세스 토큰을 생성한다. (리프래시 토큰은 데이터베이스에 저장해둔다.) 엑세스 토큰이 탈취되어도 리프래시 토큰이 없다면 다시 토큰을 발급받지 못하기 때문에 보안적 측면에서 좀 더 안전하다고 할 수 있다.
- 엑세스 토큰 : 인증 및 인가를 위해 필요
- 리프래시 토큰 : 새로운 엑세스 토큰 생성을 위해 필요
댓글