
JWT?
- 당사자 간에 정보를 JSON 개체로 안전하게 전송하기 위한 간결하고 자체 포함된 방법을 정의하는 개방형 표준
- 즉, 유저를 인증하고 식별하기 위한 토큰 기반 인증
- 토큰 자체에 사용자의 권한 정보나 서비스를 사용한 정보가 포함된다는 것이 특징
JWT 사용 하는 경우
- Authorization
- Information Exchange
JWT 구조

- header(xxxxx)
- payload(yyyyy)
- signature(zzzzz)
- 일반적으로 JWT인 토큰 유형과 HMAC SHA256 또는 RSA와 같은 사용 중인 서명 알고리즘의 두 부분으로 구성
{
"alg": "HS256",
"typ": "JWT"
}
- 그 후, 이 JSON은 JWT의 첫 번째 부분을 형성하도록 Base64Url로 인코딩 됨
payload
- 클레임은 엔티티(일반적으로 사용자) 및 추가 데이터에 대한 설명
- 클레임에는 registered, public, and private claims 의 세 가지 유형이 존재
registered claims
- 필수는 아니지만 유용하고 상호 운용 가능한 클레임 집합을 제공하기 위해 권장되는 미리 정의된 클레임 집합
- 그 중 일부는 iss (발급자), exp (만료 시간), sub (제목), aud (대상) 및 기타
public claims
- JWT를 사용하는 사람들이 마음대로 정의 가능
- 그러나 충돌을 방지하려면 IANA JSON 웹 토큰 레지스트리 에 정의하거나 충돌 방지 네임스페이스를 포함하는 URI로 정의해야 함
private claims
- 사용에 동의하고 등록된 클레임 이나 공개 클레임 이 아닌 당사자 간에 정보를 공유하기 위해 생성된 맞춤 클레임
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
- payload는 Base64Url 로 인코딩되어 JSON 웹 토큰의 두 번째 부분을 형성
signature
- JWT를 인코딩하거나 유효성 검증을 할 때 사용하는 암호화 된 코드
Access Token & Refresh Token

과정
- 사용자가 로그인
- 서버에서 사용자 확인 후, Access Token(JWT)에 권한 인증을 위한 정보를 Payload에 넣고 생성하고 Refresh Token도 생성하여 서버에 저장한 후 두 토큰 모두를 클라이언트에게 반환
- 클라이언트는 두 토큰을 저장합니다.
- 클라이언트가 권한 인증이 필요한 요청을 할 때마다 Access Token을 헤더에 실어 보냄
- 서버는 헤더의 토큰을 검증하고, Payload의 값을 디코딩하여 사용자의 권한을 확인하고 데이터를 반환
- 만약, 토큰이 만료되었다면 서버는 클라이언트에게 만료되었다는 응답을 보냄
- 클라이언트는 만료 된 토큰을 재발급 받기위해, 만료 된 Access Token과 Refresh Token을 헤더에 실어 서버에게 새로운 토큰 발급을 요청
- 서버는 Access Token과 Refresh Token을 모두 검증 한 후, Refresh Token이 만료되지 않았다면 새로운 Access Token을 발급하여 클라이언트에게 반환
레퍼런스
1. Express에서 JWT로 인증시스템 구현하기
https://velog.io/@kshired/Express%EC%97%90%EC%84%9C-JWT%EB%A1%9C-%EC%9D%B8%EC%A6%9D%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0-Access-Token%EA%B3%BC-Refresh-Token
2. Access Token & Refresh Token 사진
https://medium.com/@d971106b/%EC%82%BD%EC%A7%88%EA%B8%B0%EB%A1%9D-%EB%A1%9C%EA%B7%B8%EC%9D%B8-api-%EC%9E%91%EC%84%B1-jwt-refresh-token-access-token-http-only-92570160fa1c
3. JWT
https://jwt.io/introduction