JWT(JSON Web Token)

이 글은 JWT(JSON Web Token)에 대해 적은 글입니다. 이 포스팅을 포함해 게시된 모든 포스팅의 큰 주제는 순차적인 흐름을 지키지 않습니다. 혼란에 주의해 주세요!

---

토큰 인증과 인가에 대해 공부하다가, JWT까지 오게 되었다. 갑자기 내용이 심화되어 많이 어렵고 당황스러웠으며, 포스팅하는 지금도 아직 헷갈린 부분이 많다. 하지만, 훗날 뼈와 살이 되고...(?) 반드시 알아둬야 할 개발 지식이기에 미리 정리를 해보았다. 부족한 글이므로 언제나 태클은 환영이다.

 

JWT

JSON Web Token

JWT란 JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 클레임(Claim) 기반의 Web Token이다. JWT의 특징은 가볍고, 토큰 자체를 정보로 사용하는 자가 수용적인(Self-Contained) 방식으로 정보를 안전하게 전달한다.

 

🤔Claim 기반이 무엇이고, 왜 사용할까?

클레임이란 사용자 정보나 데이터 속성 등을 의미하며, 클레임 토큰의 토큰 안에 정보를 담을 수 있는 특징이 있다. 과거 일반 토큰 기반은 의미가 없는 문자열(String) 기반으로 구성되었다.

 

아래와 같이 일반 토큰은 의미 없는 방식으로 구성되어있다.
a9ace89aded8912ad81a8ddd891

 

그런데, 이런 일반 토큰은 단순한 문자열 방식이기 때문에 정보를 담을 수 없고, 치명적인 단점들이 존재한다.

 

1. 발급된 토큰을 만료시킬 수단이 존재하지 않는다.

2. 발급된 토큰을 검사하거나, 처리할 때마다 데이터베이스(DB)에 접근하여 검사를 해야 하며, 이는 부담스러운 작업이다.

3. 사용자 로그아웃 등으로 인한 토큰을 관리할 수 있는 수단이 없다.

 

이와 같은 문제를 해결하기 위해, 클레임을 기반으로 한 토큰을 이용하는 것이며, 클레임 기반 토큰 중 가장 대표적인 예시가 JWT가 되겠다. 이밖에도 클레임에 대해 알아야 할 정보가 있는데, 남은 내용은 아래에서 자세히 다뤄보자.

 

JWT 구조

JWT 구조 이미지 출처: www.google.com

JWT도 일반 토큰과 마찬가지로 문자열로 이루어져 있다. 여기서 특징은 ' ．'을 구분자로 하여 3가지 문자열로 나뉘어 있다는 점인데, Header, Payload, Signature 순으로 나뉘어있다.

 

Header

Header의 형태

헤더는 typ와 alg 두 가지 정보로 구성되어있다. 

 

1. typ

- 토큰의 타입을 지정한다. ex) JWT

2. alg

- 해싱 알고리즘을 지정한다.
- 주로 HMAC SHA256 또는 RSA를 사용하며 이 알고리즘은 서명(Signature)에서 사용된다.

 

🤔해싱(Hasing)?

해싱은 가변 크기의 입력값에서 고정된 크기의 출력 값을 생성해 내는 과정을 의미한다.

Payload

Payload에는 토큰에 담을 정보가 존재한다. 여기에 담는 정보의 한 '조각'을 클레임이라 부르며, name과 value의 한 쌍으로 구성되어 있다. 토큰에는 여러 개의 클레임을 넣을 수 있다. 클레임의 종류에는 크게 3가지가 있다.

 

등록된 클레임(Registered Claim)

등록된 클레임은 토큰 정보를 표현하기 위해 이미 정해진 데이터 종류이며, 모두 선택적으로 작성 가능하다. 종류는 아래와 같다.

 

iss : 토큰 발급자
sub : 토큰 제목
aud : 토큰 대상자
exp : 토큰의 만료시간
nbf : 토큰 활성 날짜. 이 날짜가 지나기 전의 토큰은 활성화되지 않는다.
iat : 토큰이 발급된 시간. 이 값을 통해 토큰 발급된 이후 시간의 경과를 알 수 있다.
jti : JWT의 고유 식별자. 중복 방지를 위해 사용하며, 일회용 토큰(ex. Access Token)에 사용된다.

 

공개 클레임(Public Claim)

공개 클레임들은 충돌이 방지된 이름을 가지고 있어야 한다. 충돌을 방지하기 위해, 클레임 이름을 URI형식으로 생성한다.

 

URI 예시

🤔URI? URL?

URI

통합 자원 식별자(Uniform Resource Identifier). 즉, URI는 인터넷에 있는 자원을 나타내는 유일한 주소이다. URI의 존재는 인터넷에서 요구되는 기본 조건으로서 인터넷 프로토콜에 항상 붙어 다닌다.

 

URL

파일식별자(Uniform Resource Locator) 혹은 유일자원지시기라 불리는 URL은 네트워크 상에서 자원이 어디 있는지를 알려주기 위한 규약이다. 쉽게 정리하면, 우리는 URL을 흔한 웹 사이트 주소로 알고 있다. 하지만, URL은 주소뿐만 아니라, 컴퓨터 네트워크 상의 자원을 모두 나타낼 수 있다. 해당 주소를 접속하려면 URL에 맞는 프로토콜을 알아야 하고, 그와 동일한 프로토콜에 접속해야 한다.

 

구분해보기

 

예시 주소
https://ivorycode.tistory.com/manage/newpost/?type=post&returnURL=%2Fmanage%2Fposts%2F

위의 주소에서 path 부분인 'newpost'까지가 URL
https://ivorycode.tistory.com/manage/newpost

protocol부터 query string까지 전부를 URI
https://ivorycode.tistory.com/manage/newpost/?type=post&returnURL=%2Fmanage%2Fposts%2F

식별하는 부분
?type=post&returnURL=%2Fmanage%2Fposts%2F

 

비공개 클레임(Private Claim)

사용자 정의 클레임으로 서버와 클라이언트 사이에 임의로 지정한 정보를 저장하는 클레임.

 

비공개 클레임 예시

예제 Payload

 

예시로 작성한 Payload

Signature

서명은 JWT의 마지막 부분이며, 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드이다. 서명은 Header와 Payload의 값들을 BASE64로 인코딩하고, 그 값을 비밀키로 하여 Header에서 정의한 알고리즘으로 해싱을 한다. 이 과정에서 나온 값을 다시 BASE64로 인코딩하여 생성한다.

 

🤔BASE64 인코딩?

 

인코딩

정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약 등을 위해서 다른 형태나 형식으로 변환하는 처리 혹은 그 처리 방식을 말한다.

 

BASE64

8비트 이진 데이터를 문자 코드에 영향을 받지 않는 공통 ASCII 영역의 문자들로만 이루어진 일련의 문자열로 바꾸는 인코딩 방식을 가리키는 개념 - 출처: 위키백과

 

😢검색해보니 꽤 깊은 내용이었다... 우선 직역하여 64진법 인코딩, 컴퓨터가 이해할 수 있도록 BASE64 인코딩 과정을 한다고 생각하는 중이다...

 

JWT 고려사항

JWT를 개념을 설명하며 일반적인 토큰 방식을 잠깐 언급했었다. 일반 토큰 방식과 비교하면, JWT는 정말 편리하고 용이한 토큰이라고 생각된다. 하지만, 그만큼 고려해야 할 사항과 단점들이 있었고, 해당 내용과 관련하여 '망나니개발자'님의 포스팅을 일부 발췌하였다.

 

Self-contained : 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다.

토큰 길이 : 토큰의 페이로드(Payload)에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다.

Payload 인코딩 : 페이로드(Payload) 자체는 암호화된 것이 아니라, BASE64로 인코딩 된 것이다. 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, JWE로 암호화하거나 Payload에 중요 데이터를 넣지 않아야 한다.

Stateless : JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능하다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 한다.

Tore Token : 토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 한다.

 

💯 참고 자료 출처

'망나니개발자'님 블로그

mangkyu.tistory.com/56

[Server] JWT(Json Web Token)란?