JWT (JSON Web Token) 소개

What is JWT (JSON Web Token)

정보를 JSON 개체로 전송하기 위한 토큰 기반 인증

Why use JWT

비밀스러운 정보를 전달할 때 서명된 토큰을 활용하면 무결성을 확인할 수 있고 외부에 정보를 숨길 수 있다

When use JWT

크게 두가지 시나리오 사용되는데,

- 사용자가 요청부분에 JWT가 포함되어 JWT 토큰으로 허용되는 경로, 서비스 및 리소스에 접근할 수 있다

single sign on 방식은 오버헤드가 적고 여러 도메인에서 쉽게 사용할 수 있어 널리 사용되는 방식이다

(권한부여, Authorization)

 

- 공개/개인 키 쌍을 사용하여 JWT에 서명할 수 있기 때문에 발신자가 누구인지 확인할 수 있고 header 와 payload를 사용하여 서명을 계산하므로 콘텐츠가 변조되지 않았는지 확인할 수 있다 (정보교환, Information Exchange)

 

single sign on

* single sign on (단일 인증) : 한번의 인증 과정으로 여러 컴퓨터 자원을 이용 가능하게 하는 인증 기능

* overhead : 어떠한 처리를 하기 위해 들어가는 추가 처리 시간 및 메모리

 

What is stateless

무상태 라고 불리는 HTTP 통신의 특징이다

서버가 클라이언트의 상태를 보존하지 않음을 의미한다

장점 : 서버 트래픽이 증가할 때 Scaling 을 진행하게 되는데 서버는 session 관리를 하지 않아 트래픽에 의한 확장에서 자유로울 수 있다

단점 : 클라이언트가 요청할 때마다 상태정보를 전달해야 하기 때문에 네트워크 리소스를 소비해야 한다

 

 

What is stateful

상태유지 라고 불리는 HTTP 통신의 특징이다서버가 클라이언트의 이전상태를 기록하는 것을 의미한다

장점 : 서버가 사용자의 상태 cookie 또는 session 정보를 기억하고 있다가 필요한 상황이 생겼을 때 활용할 수 있다

단점
1. 서버 트래픽이 증가해 Scaling 을 진행할 때 사용자 정보가 공유되지 않는다
2. 사이트 간 요청 위조 CSRF (Cross-site request forgery) : 세션 보안 문제
- 웹 브라우저를 속여 사용자가 로그인한 응용 프로그램에서 원치않는 작업을 실행하도록 하는 공격
(ex. 세션, 쿠키 도난, 무단 자금 이체, 비밀번호 변경 및 데이터 도난)

- 완화 방법
1. 사용하지 않을 때 웹 애플리케이션 로그오프
2. 사용자 이름 및 암호 보안
3. 브라우저가 비밀번호를 기억하도록 허용안함
4. 애플리케이션에 로그인한 상태에서 동시에 탐색 방지

3. 교차 출처 리소스 공유 CORS (Cross-origin resource sharing) : 도메인 리소스 문제
간단히 말하면, 웹페이지를 불러오는데 도메인이 서러 다른 콘텐츠를 가져오려고 할 때 생기는 문제이다

 

 

CSRF

 

 

CORS

 

실시간 연동이 필요한 서버는  Stateful Server 적합 (ex. MMORPG)
실시간 연동이 적은 서버는 네트워크 비용을 줄이기 위해 Stateless Server 적합

 

* Stateful 과 Stateless 실제사례를 통해 잘 설명해주는 글이 있다https://irostub.github.io/web/stateful-stateless/

Stateful과 Stateless의 이해

 

What is JWS (JSON Web Signature)

JSON으로 전자 서명을하여 URL-Safe 문자열로 표현한 것

 

What is JWE (JSON Web Encryption)

JSON을 암호화하여 URL-Safe 문자열로 표현한 것

 

* URL-Safe : URL에 포함할 수 없는 문자를 포함하지 않는 것

JWT Architecture

JWT 는 총 세 부분 (  .  ) 으로 구분되어 구성된다

• Header
• Payload
• Signature

 xxxx.yyyy.zzzz 

 

세 부분을 분해해서 분석해 보면,

JWT header

헤더(header)는 토큰 유형과 사용중인 서명 알고리즘 두 부분으로 구성된다

 

JWT payload

페이로드(payload)는 Claim 을 포함한다 또한, 클레임은 등록, 공개, 비공개 클레임으로 세가지 유형으로 구성된다

 

- Registered claims

> 미리 정의된 클레임 집합

• iss : 토큰 발급자 (issuer)
• sub : 토큰 제목 (subject)
• aud : 토큰 대상자 (audience)
• exp: 토큰 만료 시간 (expiration), NumericDate 형식으로 되어 있어야 함 ex) 1480849147370
• nbf : 토큰 활성 날짜 (not before), 이 날이 지나기 전의 토큰은 활성화 되지 않는다
• iat : 토큰 발급 시간 (issued at), 토큰 발급 이후의 경과 시간을 알수 있다
• jti : 토큰 식별자 (JWT ID), 중복 방지를 위해 사용하며 일회용 토큰(Access Token) 등에 사용

 

- Public claims

> 사용하는 사람들이 마음대로 정의할 수 있지만 충돌을 방지하려면 충돌 방지 네임스페이스를 포함하는 URI 정의해야 된다

- Private claims

> 사용에 동의하고 등록되거나 공개클레임이 아닌 정보 공유를 위해 생성된 맞춤 클레임

 

JWT signature

서명(signature) 부분을 생성하려면 인코딩된 헤더, 인코딩된 페이로드, 암호, 헤더에 지정된 알고리즘을 가져와서 서명한다

 

HMAC SHA256 알고리즘을 사용하려는 경우 서명은 JWT signature 사진과 같이 생성된다

서명은 메시지가 도중에 변경되지 않았는지 확인하는데 사용되며 개인 키로 서명된 토큰은 JWT 를 보낸사람이 누구인지 확인할 수 있다

 

위의 개념을 모두 합쳐 Base64 로 인코딩되어 JWT 가 완성된다

 

Base64-URL 문자열

 

* Claim : 엔터티 및 추가 데이터에 대한 설명

* Entity : 인간의 개념 또는 의미있는 정보 집합

JWT Mechanism

jwt mechanism

 

Application or Client 가 Authorization Server 에 권한 부여를 요청 >

권한이 부여되면 Authorization Server 는 Application 에 액세스 토큰을 반환 >

Application 은 액세스 토큰을 사용하여 보호된 API 에 접속

 

사용자가 보호된 경로 or 리소스에 액세스 할 때마다 사용자 에이전트는 Authorization 헤더에서 Bearor 스키마를 사용하여 JWT 를 보낸다

 

Authorization header schema

토큰이 Authorization 헤더로 전송되면 CORS (Cross-Origin Resource Sharing)는 쿠키를 사용하지 않아 문제가 되지 않는다

 

JWT Libraries List

• com.auth0
• org.bitbucket.b_c
• com.nimbusds
• io.jsonwebtoken
• io.fusionauth
• io.vertx

 

JWT 공식홈에서는 다양한 언어로 JWT 를 구현하는 라이브러리를 제공하고 있다

그 중에서 Java 언어로 구현하라고 제공해주는 라이브러리 6개 목록

 

JWT 를 구현하는 라이브러리 중 어떤걸 사용할까 고민을 하다

com.auth0

 

io.fusionauth

 

io.vertx

 

io.jsonwebtoken

org.bitbucket.b_c 와 com.nimbuds 라이브러는 Bitbucket 플랫폼에 저장되고 있다

 

6개 중 하나를 사용하면 JWT 구현은 되겠지만 개발자들이 많이 사용하면서 레퍼런스가 많은 io.jsonwebtoken 을 사용하기로 했다

 

How to use JWT

업데이트 준비중 .....

---

https://jwt.io/introduction

JWT.IO

https://datatracker.ietf.org/doc/html/rfc7519

rfc7519

https://spring.io/guides/gs/securing-web/

Securing a Web Application

---