토큰(JWT, AccessToken,RefreshToken)

목차

인증, 인가란

인증(Authentication)

: 사용자를 확인하는 과정으로, 요청으로 보내온 클라이언트가 DB 서버에 등록되어 있는지를 확인하여 서버가 접속한 주체를 파악한다.

인가(Authoriztion)

: 사용자가 해당 페이지에 접속할 권한을 가지고 있는지 확인한다.

 

인증 시스템이 필요한 이유

우리가 대부분 이용하는 웹 어플리케이션은 HTTP를 통해 통신하지만, 무상태성 프로토콜이기에 상태를 유지하지 않는다. 

어떤 클라이언트가 보내온 요청인지 서버는 구분하지 못하고, 과거의 정보를 기반으로 클라이언트를 판단할 수 없다.

그렇기에 서버는 쿠키를 이용해 사용자를 구분하는 작업(인증)을 하게 되었고, 클라이언트로부터 본인만 알 수있는 등록된 정보를 받아 확인하는 작업을 통해 사용자를 구분하게 되었다. 

 

세션 기반 인증은 클라이언트에서 유저 정보를 요청 할 때마다 해당 정보를 줘도 되는지에 대해 세션 값 일치여부를 확인했었다. 매 요청마다 DB를 살펴보는 것이 불편하고, 부담이 되었기 때문에 토큰 기반 인증 개념이 생겨났다.

*세션 기반 인증

로그인 과정:
사용자가 웹 애플리케이션에 로그인하면, 서버는 사용자를 인증하고 세션을 생성한다.
세션은 일반적으로 서버 측에 저장되며, 세션에는 사용자에 대한 고유한 식별자 및 다양한 상태 정보가 포함될 수 있다.

세션 식별자:
클라이언트는 세션 식별자(session ID)를 받게 되는데, 이는 서버에서 생성된 고유한 값이다.
일반적으로 세션 ID는 쿠키를 통해 클라이언트에 저장되어 나중에 사용자를 식별하는 데 활용된다.

세션 유지:
로그인 후, 클라이언트는 세션 ID를 서버에 전송하여 자신을 식별한다.
서버는 세션 ID를 기반으로 세션을 찾아 사용자의 상태를 확인하고 유저 정보를 제공하거나 기능을 수행한다.

세션 만료 및 로그아웃:
세션은 특정 시간 동안 유효하며, 일반적으로 일정 시간이 지나면 만료된다.
사용자가 로그아웃하거나 일정 시간 동안 활동이 없을 경우 세션이 종료된다.

토큰이란?

클라이언트에서 인증 정보를 보관하는 방법이다. 

JWT란(Json Web Token)

 일반적으로 클라이언트와 서버 사이에서 통신할 때 권한을 위해 사용하는 토큰이다.

웹 상에서 정보를 Json형태로 주고 받기 위해 표준규약에 따라 생성한 암호화된 토큰으로 복잡하고 읽을 수 없는 string 형태로 저장되어있다.

JWT 구성요소

헤더(header), 페이로드(payload), 서명(signature) 세 파트로 나눠져 있다.

 

• 헤더 (Header)
  어떠한 알고리즘으로 암호화 할 것인지, 어떠한 토큰을 사용할 것인지에 대한 정보가 들어있다.

• 정보 (Payload)
  전달하려는 정보(사용자 id나 다른 데이터들, 이것들을 클레임이라고 부른다)가 들어있다.
  payload에 있는 내용은 수정이 가능하여 더 많은 정보를 추가할 수 있다. 그러나 노출과 수정이 가능한 지점이기 때문에 인증이 필요한 최소한의 정보(아이디, 비밀번호 등 개인정보가 아닌 이 토큰을 가졌을 때 권한의 범위나 토큰의 발급일과 만료일자 등)만을 담아야한다.

• 서명 (Signature)
  가장 중요한 부분으로 헤더와 정보를 합친 후 발급해준 서버가 지정한 secret key로 암호화 시켜 토큰을 변조하기 어렵게 만들어준다.
  한가지 예를 들어보자면 토큰이 발급된 후 누군가가 Payload의 정보를 수정하면 Payload에는 다른 누군가가 조작된 정보가 들어가 있지만 Signatute에는 수정되기 전의 Payload 내용을 기반으로 이미 암호화 되어있는 결과가 저장되어 있기 때문에 조작되어있는 Payload와는 다른 결과값이 나오게 된다.
  이러한 방식으로 비교하면 서버는 토큰이 조작되었는지 아닌지를 쉽게 알 수 있고, 다른 누군가는 조작된 토큰을 악용하기가 어려워진다👍

 JWT의 동작원리

 

1. 사용자가 id와 password를 입력하여 로그인 시도
2. 서버는 요청 확인 후, secret key를 통해 Access Token 발급
3. JWT 토큰(Access Token)을 클라이언트에게 전달
4. 클라이언트에서는 API를 요청할 때마다 Authorization header에 Access Token 담아서 요청
5. 서버는 JWT Signature 체크하고, Payload로부터 사용자 정보를 확인해 데이터 반환

JWT를 사용하는 가장 큰 이유는 클레임(Claim) 토큰 기반 인증이 주는 편리함이 가장 크다고 할 수 있다.

일반 토큰 기반 인증은, 토큰을 검증할 때 필요한 관련 정보들을 서버에 저장해두고 있었기 때문에 항상 DB에 접근해야만 했다.

session 방식 또한 저장소에 저장해두었던 session ID를 찾아와 검증하는 절차를 가져 다소 번거롭게 느껴지곤 했다. 

 

하지만, 클레임 토큰 기반으로 이루어진 JWT는 사용자 인증에 필요한 모든 정보를 토큰 자체에 담고 있기 때문에 별도의 인증 저장소가 필요 없다.

JWT 종류

1. Access Token

2. Refresh Token

Access Token

클라이언트가 가지고 있는 실질적인 사용자의 자격 증명 정보가 담긴 토큰으로 보호된 정보들에 접근할 수 있는 권한부여에 사용한다.
클라이언트에서 요청이 오면 서버는 해당 토큰에 있는 정보를 활용하여 사용자 정보에 맞게 응답을 진행한다.

Refresh Token

새로운 Access Token을 재발급해주기 위해 사용하는 토큰으로 보통 데이터베이스에 유저 정보와 같이 기록된다

 

두 가지 토큰을 사용하는 이유는 무엇일까?

Access Token는 사용자의 자격 증명 정보가 들어가 있기 때문에 해당 토큰이 탈취 당할 가능성이 크다. 그런 문제를 대응하기 위해 Access Token의 유효 기간은 비교적 짧게 설정해 탈취되더라도 오랫동안 사용할 수 없도록 한다.

Refresh Token 의 재발급 과정

1. 로그인 인증에 성공한 클라이언트는 Refresh Token과 Access Token 두 개를 서버로부터 받는다.
2. 클라이언트는 Refresh Token과 Access Token을 로컬에 저장해놓는다.
3. 클라이언트는 헤더에 Access Token을 넣고 API 통신을 한다. (Authorization)
4. 일정 기간이 지나 Access Token의 유효기간이 만료되었다.
   4.1. Access Token은 이제 유효하지 않으므로 권한이 없는 사용자가 된다.
   4.2. 클라이언트로부터 유효기간이 지난 Access Token을 받은 서버는 401 (Unauthorized) 에러 코드로 응답한다.
   4.3. 401를 통해 클라이언트는 invalid_token (유효기간이 만료되었음)을 알 수 있다.
5. 헤더에 Access Token 대신 Refresh Token을 넣어 API를 재요청한다.
6. Refresh Token으로 사용자의 권한을 확인한 서버는 응답쿼리 헤더에 새로운 Access Token을 넣어 응답한다.
7. 만약 Refresh Token도 만료되었다면 서버는 동일하게 401 error code를 보내고, 클라이언트는 재로그인해야한다.

AccessToken과 RefreshToken 저장위치

AccessToken : 클라이언트 측의 메모리에 저장

RefreshToken : 서버 측에 저장 

 

자료 출처 및 참고 블로그

https://velog.io/@hahan/JWT%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

JWT란 무엇인가?

https://velog.io/@boo1996/Token

Token

http://www.opennaru.com/opennaru-blog/jwt-json-web-token/

JWT (JSON Web Token) 이해하기와 활용 방안 - Opennaru, Inc.

https://hudi.blog/session-based-auth-vs-token-based-auth/

세션 기반 인증과 토큰 기반 인증 (feat. 인증과 인가)