Token

이상연·2023년 12월 19일

JWT Token access token refresh-token

Token의 특징

Stateless(무상태성) 방식

상태 유지를 하지 않는 것
유저의 인증 정보를 서버나 세션에 담아두지 않음

Scalability(확장성) 향상

세션이 존재하지 않으니, 유저들이 로그인 되어있는지 안되어있는지 신경 X
즉, 서버와 클라이언트의 연결고리가 없기 때문에 서버의 확장성이 높아짐

Token 담는 방식

표준적으로 Authorization header에 담게 됨
Bearer이라는 type 을 앞에 붙이고 뒤에는 해당 Token의 인증 스키마를 담는다.

Header
{Authorization: Bearer '인증토큰 스키마' }

JWT(Json Web Token)

JWT는 인증에 필요한 정보들을 암호화시킨 JSON Token 이다.

JWT 기반 인증은 JWT 토큰(Access Token)을 HTTP헤더에 실어 서버가 클라이언트를 식별하는 방식이다.

JSON 데이터를 인코딩하여 직렬화 하며, 토큰 내부에는 위변조 방지를 위해 개인키를 통한 전자서명도 들어있다.

JWT 구조

사진출처 : VELOPERT.LOG

Header(헤더)

typ : 토큰의 타입을 지정
**alg** : 해싱 알고리즘을 지정

{
  "typ": "JWT",
  "alg": "HS256"
}

Payload(정보)

Payload에 담은 정보의 한 ‘조각’을 ****클레임(Claim)****이라고 부르며, 키와 값으로 이루어져있음
Registered Claim (등록된 클레임)
- 서비스에서 필요한 정보들이 아닌, 토큰에 대한 정보를 담기 위해 이미 정해진 클레임
**Public Claim (공개 클레임)**
- 사용자가 정의할 수 있는 클레임 공개용 정보 (전달을 위해 사용함)

**Private Claim (비공개 클레임)**

해당하는 클라이언트와 서버 간에 정보를 공유하기 위해 만들어진 사용자 지정 클레임

외부에 공개되어도 상관없지만 해당 유저를 특정할 수 있는 정보들을 담는다.

{
    "iss": "velopert.com", //발행자 ( Registered Claim )
    "exp": "1485270000000",  // 만료시간 ( Registered Claim )
    "https://velopert.com/jwt_claims/is_admin": true,  // Public Claim
    "userId": "11028373727102",
    "username": "velopert"
}

Signature(서명)

헤더에서 정의한 알고리즘 방식을 사용함
구조 : (헤더 + 페이로드)와 서버가 갖고있는 key 값을 합친 것을 헤더에서 정의한 알고리즘으로 암호화 시킴

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

Access Token 과 Refresh Token

Access Token : 실질적으로 접근에 관여하는 토큰

Refresh Token : 재발급에 관여하는 토큰

Refresh Token을 사용하는 이유?

Access Token 만을 이용하면 **제 3자에게 탈취당할 경우 보안에 취약**하게 됨

Access Token이 탈취당했을 때 JWT는 발급 후에 삭제가 불가능하기 떄문에, 만료시간을 설정해야함

그래서 Access Token의 만료기간을 짧게 잡고, 만료될 때마다 Refresh Token을 이용하여 Access Token을 재발급 받는 형식

JWT 인증 과정

클라이언트가 서버에 로그인 인증을 요청함
서버가 클라이언트에게 JWT를 생성하고, Access Token, Refresh Token을 쿠키에 담아 클라이언트에게 전달
클라이언트는 서버로부터 받은 JWT를 로컬 스토리지에 저장하고 API를 서버에 요청할 때 Authorization header에 Access Token을 담아서 보냄
서버는 JWT가 서버내에 발행한토큰인지 확인하고, 인증이 통과되었으면 payload에 있는 유저의 정보들을 클라이언트에게 전달함
클라이언트가 서버에 요청했을 때, Access Token이 만료되면, Refresh Token을 이용하여 토큰 재발급을 받음
서버로부터 새로운 엑세스 토큰을 발급 받음

JWT 장점

Siginature을 생성하므로 데이터 위변조를 막을 수 있음
인증 정보에 대한 별도의 저장소가 필요 없음
서버가 무상태가 되어서 서버 확장성이 우수해짐
토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능
모바일에서도 작동 잘함 (세션은 불가능)
OAuth의 경우 소셜 계정을 이용하여 다른 웹 서비스에서도 로그인 할 수 있따.

JWT 단점

Self-contained : 토큰 자체에 정보를 담고 있으므로 오히려 위험할 수도 있음
토큰 길이 : 토큰의 길이가 길기 때문에, 네트워크에 부하를 줄 수 있음
Payload 인코딩 : Payload는 암호화가 아닌, 인코딩이기 떄문에 중간에 탈취하여 디코딩하면 데이터를 볼 수 있으므로, payload에 중요한 데이터 넣으면 안됨
Store Token : 무상태 특징을 가지기 떄문에, 토큰은 클라이언트 측에서 관리해서 토큰 자체를 탈취당하면 대처하기가 어려움

이상연

이전 포스트