일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- nest jwt
- gcp ssh
- Nest.js
- nest login
- docker mysql설치하기
- InnerJoinMapOne
- Nest.js 로그인
- vm ssh 포트
- 맥 포트확인
- ssh 연결 방법
- 맥 포트닫기
- vm ssh 포트 변경
- gcp ssh 포트 변경
- How to Join Tables Without Relations in TypeORM
- vm ssh
- nest passport
- ssh 포트 변경
- ssh연결
- JWT
- jwt장점
- local database
- JWT쓰는이유
- Nest.js login
- gcp ssh vm
- nest authentication
- macOS ssh
- port 22: Operation timed out
- 맥 사용하는 포트 확인
- ssh vm연결
- vm ssh port
- Today
- Total
Seize the day
JWT(JSON Web Token)이란? 본문
JSON Web Token(JWT)은 JSON 객체로 정보를 안전하게 전송하는 방법의 일종으로 공개된 표준(RFC 7519)이다. 말 그대로 필요한 정보들을 token에 담아 암호화 시켜 사용하는 것입니다.
JWT는 서명된 토큰(signed token)이라고 강조되고 있다. 공개/개인 키를 쌍으로 사용하여 서명할 경우 이 서명은 비공개 키를 보유하고 있는 당사자만이 그 토큰을 서명했다는 것을 보장한다. 즉, 키를 보유한 서버가 이 토큰이 정상적인지 알 수 있다.
JWT 구조
JWT는 헤더(Header), 페이로드(Payload), 서명(Signature)으로 구성 되어 있다.
각 부분은 Base64로 인코딩 되고, 점(.)으로 구분자로 사용된다.
xxxxx.yyyyy.zzzzz
Header
{
"alg": "HS256",
"typ": "JWT"
}
헤더에는 두가지의 주요 정보를 가지고 있다. 토큰의 타입(typ)와 사용된 서명 알고리즘(alg)이다. 서명 알고리즘은 서명을 생성하고 검증할 때 사용된다.
typ은 JWT
로 지정되며, alg는 HMAC, SHA256 등 작성한다.
위 예시대로라면 개인키로 HS256 알고리즘을 사용한다.
라는 의미이다.
Payload
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
페이로드는 토큰에 전달하고자 하는 Claim을 포함한다.
사용자 식별 정보 또는 토큰에 대한 property
를 key-value
형태로 저장한다. 즉, 개발자 마음대로 넣어도 된다는 뜻~
표준 스펙상 key의 이름은 컴팩트하게 3글자로 정의한다.
registered claim
은 아래와 같이 있다.
- iss (Issuer) : 토큰 발행자(토큰 발행자의 고유 식별 정보를 포함)
- sub (Subject) : 토큰이 대상으로 하는 주체
- aud (Audience) : 토큰 수신자
- exp (Expiration Time) : 토큰 만료 시간 (이 시간이 지나면 더이상 유효 하지 않음)
- nbf (Not Before) : 토큰 활성 날짜 (이 시간 이전에는 토큰을 사용 할 수 없음)
- iat (Issued At) : 토큰 발행 시간
- jti (JWT Id) : JWT 토큰 식별자 (issuer가 여러 명일 때 이를 구분하기 위한 값)
이 외의 값들 중 필요한 값이 있다면 추가해서 사용해도 무관하다.
단, payload는 암호화가 되지 않은 서명된 값이 아니기 때문에 민감한 정보를 담지 않는다.
디코딩하면 누구나 열람이 가능하다. jwt.io 사이트에서도 바로 확인 할 수 있다.
Signature
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
your-256-bit-secret
)
Header와 Payload를 base64로 인코딩 값을 구분자 점(.)으로 연결하고 your-256-bit-secret 서버가 가지고 개인키를 사용하여 서명한다. 따라서 서명(Signature)은 토큰을 발행한 서버만이 개인키로 암호화를 풀 수 있다.
복호화를 생각해 보면, 개인키로 Signature를 복호화한 다음 base64UrlEncode(header)가 JWT의 heaer값과 일치한 지, base64UrlEncode(payload) 와 일치한 지 확인하면 알 수 있다.
서명을 제외한 헤더와 페이로드는 인코딩만 되어 있어 본문의 정보를 볼 수 있지만, 서명을 통해 정보의 무결성과 보안이 유지된다.
JWT는 필요한 모든 정보를 자체적으로 가지고 있는 Self-contained로, stateful 해야 하는 세션의 단점을 보완하기 위해 만들어진 JWT는 별도의 저장소가 필수적이지 않다.
서버 측에서 세션을 유지할 필요 없어 stateless하여, 분산 시스템이나 마이크로서비스 아키텍처에서의 확장성이 높다.
Signature, 디지털 서명을 통해 보호되며, 데이터의 무결성을 보장할 수 있다.
'개발' 카테고리의 다른 글
[Docker] MySQL 설치 (0) | 2022.04.03 |
---|---|
[macOS] 사용하고 있는 port 확인 (0) | 2022.02.13 |
Google Domains에서 도메인 구입하기 (0) | 2022.02.04 |