로그인 기능 및 인증/1. JWT

JWT2. 기본 개념

혀닙 2022. 3. 3. 01:24

목차

  1. JWT란?
  2. JWT 사용례
  3. JWT의 구성
  4. 장단점
  5. 프로세스


# 1 . JWT란?

  • JSON Web Token의 약자
  • 전자 서명 된 URL-safe (URL로 이용할 수있는 문자로 구성된)의 JSON.
  • 속성 정보 (Claim)를 JSON 데이터 구조로 표현한 토큰으로 RFC7519 표준.
  • JWT는 서버와 클라이언트 간 정보를 주고 받을 때, Http request객체의 header에 JSON 토큰을 넣은 후 서버는 별도의 인증 과정없이 헤더에 포함되어 있는 JWT 정보를 통해 인증.
  • 이때 사용되는 JSON 데이터는 URL-Safe 하도록 URL에 포함할 수 있는 문자만으로 생성
  • JWT는 HMAC 알고리즘을 사용하여 비밀키 또는 RSA를 이용한 Public Key/ Private Key 쌍으로 서명 가능

#2. 사용례

  • 사용자가 로그인 시,서버는 사용자의 정보를 기반으로한 토큰을 발급
  • 그 후, 클라이언트가 서버에 요청을 할 때 마다 JWT를 포함하여 전달
  • 매 요청 시, 서버는 해당 토큰이 유효하고 인증됐는지 검증을 하고, 사용자가 요청한 작업에 권한이 있는지 확인하여 작업을 처리
  • 서버에서는 사용자에 대한 세션을 유지 할 필요가 없음
  • 즉 사용자가 로그인되어있는지 안되어있는지 신경 쓸 필요가 없고, 사용자가 요청을 했을때 토큰만 확인하면 됨
  • 세션 관리가 필요 없어서 서버 자원과 비용을 절감 가능
 

# 3. JSON 토큰의 구성

  • JWT는 세 파트로 나누어지며, 각 파트는 점로 구분하여 xxxxx.yyyyy.zzzzz 와 같은 식으로 표현됨
  • 순서대로 헤더 (Header), 페이로드 (Payload), 서명 (Sinature)로 구성

# 3-1. 헤더(header)

  • 암호화 알고리즘 즉, 해싱 알고리즘으로 보통 HMAC SHA256 또는 RSA가 사용됨
  • 헤더에 작성되어 있는 알고리즘은, 토큰 검증 시 사용되는 서명(signature) 부분에서 사용됨

const header = {
    typ : "JWT",		//토큰의 타입
    alg : "HS256"		//암호화 알고리즘
}




# 3-2. 페이로드(payload)

  • 토큰에 담을 클레임(claim) 정보를 포함
  • 각 claim은 key와 value의 쌍으로 이루어짐
  • 클레임 정보 : 등록된(registered) 클레임 / 공개(public) 클레임 / 비공개(private) 클레임
const payload = {
//등록된 클레임
    iss : "발급자(issuer)",
    sub : "토큰 제목(subject)",
    aud : "토큰 대상자(audience)",
    exp : "토큰 만료 시간(expiration)",	//numericdate 형식 + 반드시 현재 시간 이후
    nbf : "토큰 활성 날짜(NotBefore)",	//numericdate 형식 + nbf 이후 토큰 처리됨
    iat : "토큰 발급 시간(issued at)",	//토큰의 age 확인 가능
    jti : "고유 식별자",		//JWT 고유 식별자. 주로 중복 처리 방지를 위해 사용, 1회용 토큰에서 유용
    
//공개 클레임
	uri : true,			//충돌이 방지된 key를 가져야함. 충돌 방지를 위해 uri형식으로 이름 지음
    
//비공개 클레임
	key : value			//클-서버 간 협의 하에 사용되는 클레임 이름
}

 

# 3-3. 서명(signature)

  • 서명은 헤더의 인코딩 값, 페이로더의 인코딩 값을 합친 후 주어진 비밀키(secret key)로 해쉬 생성

 

#4. JWT Process

-기존의 토큰 방식인증!
다이어그램에 표시된 것처럼 토큰은 이후의 모든 서비스 호출에 사용
서비스를 받기 위해서는 토큰의 유효성을 확인하여 세부 정보를 쿼리해야 했음
참조에 의한 호출(By Reference) 형태로 모든 서비스는 항상 상호 작용할 때 다시 접속해야함
>한마디로 불편

-JWT 방식 : 값에 의한 호출이 가능한 토큰
토큰이 필요한 모든 정보를 포함하고 있어(자기 수용적) 참조(적어도 인증 및 권한 부여를 위해)가 필요없기 때문에 마이크로서비스 자체에서 유효성을 검증

-프로세스

  1. 사용자가 id와 password를 입력하여 로그인을 시도
  2. 서버는 요청을 확인하고 secret key를 통해 Access token을 발급
  3. JWT 토큰을 클라이언트에 전달
  4. 클라이언트에서 API 을 요청할때  클라이언트가 Authorization header에 Access token을 담아서 보냄
  5. 서버는 JWT Signature를 체크하고 Payload로부터 사용자 정보를 확인해 데이터를 반환
  6. 클라이언트의 로그인 정보를 서버 메모리에 저장하지 않기 때문에 토큰기반 인증 메커니즘을 제공
  7. 인증이 필요한 경로에 접근할 때 서버 측은 Authorization 헤더에 유효한 JWT 또는 존재하는지 확인
 
 

# 5. 장단점

- 장점

  • 인증에 필요한 모든 정보는 토큰 자체(payload)에 포함하기 때문에 별도의 인증 저장소가 필요없음(self contained 관련)
  • 데이터 베이스와 같은 서버와의 커뮤니케이션 오버헤드를 최소화(self contained 관련)
  • 분산 마이크로 서비스 환경에서 중앙 집중식 인증 서버와 데이터베이스에 의존하지 않는 쉬운 인증 및 인가 방법을 제공.
  • Cross-Origin Resource Sharing (CORS)는 쿠키를 사용하지 않기 때문에 ,두 도메인에서 API를 제공하더라도 문제가 발생 x
 
 

[참고] JSON 웹 토큰의 사용을 권장하는 몇 가지 이유

  • URL  파라미터와 헤더로 사용
  • 수평 스케일이 용이
  • 디버깅 및 관리가 용이
  • 트래픽 대한 부담이 낮음
  • REST 서비스로 제공 가능
  • 내장된 만료
  • 독립적인 JWT


- 단점

  • 토큰은 클라이언트에 저장되어 데이터베이스에서 사용자 정보를 조작하더라도 토큰에 직접 적용불가
  • 더 많은 필드가 추가되면 토큰이 커질 수 있음
  • 비상태 애플리케이션에서 토큰은 거의 모든 요청에 대해 전송되므로 데이터 트래픽 크기에 영향을 미칠 수 있음

 

 

 

Reference :

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