| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- 구글 자바 스타일
- 신입개발자
- 세션장점
- jwt토큰관리
- session단점
- session이란?
- Google Java Style Guide
- 자바 코드 가이드
- session장점
- GPT프로젝트
- 백엔드 서버
- jwt원리
- session이 뭔가요?
- 세션단점
- 토큰구조
- 신입개발자 프로젝트
- Google Java Code Style Guide
- jwt토큰원리
- jwt란?
- jwt토큰구조
- 우아한테크코스 Google Java Style Guid
- 메모리에서 배열
- 세션장단점
- 프록시서버
- 포워드프록시
- 배열과 메모리
- 프로그래밍 배열
- 구글 자바 코드 스타일
- ReverseProxy
- session이뭔가요?
- Today
- Total
dev_dbdb1114
JWT토큰에 대해서 본문
JWT는 공식문서에 의하면 RFC7519 기반이라고하며, RSA 암호화 방식을 사용한다.
RFC 7519
인터넷이 처음 발달되기 시작할 때 서로다른 내부망을 연결하기 위해 처음으로 약속된 규칙이 RFC 1번 문서였다. 그리고 또 다른 내부망을 연결하기 위한 더해서 만들어진 규칙이 RFC 2번 3번 ... 이어져 만들어진 것이 1000단위 까지 만들어졌다.
결국 이런 RFC문서로 이루어진 것이 WordWideWeb 의 기반을 이루며, 이것이 http프로토콜인데 이 RFC문서에서 7519번째 규약으로 만들어진 것이 JWT 토큰이다.
RSA 암호화
기본적으로 RSA 암호화는 두 개의 key를 가지고 암호화와 복호화에 이용한다.
공개키 : 개인키로 암호화된 정보를 읽을 수 있음.
개인키 : 개인키로 암호화하면, 공개키로 정보를 읽을 수 있음. 만약에 공개키로 어떤 정보가 열린다면, 이것은 인증된 정보라고 할 수 있음.
어떻게 사용하는가? 아래와 같다 아래 예시는 A라는 유저가 B 서버에 요청을 보낼 때를 조금 더 쉽게 설명한 것이다.
Case1
A --> B
A가 B에게 요청을 보낼 때 A의 "개인"key를 이용해서 암호화함.
B가 "개방"Key로 복호화 했을 때 열리면
이것은 A가 "개인"key를 이용해 암호화한 것으로 확신할 수 있음.
( 전자문서의 서명이라는 것이고, A가 맞다는 증명이 되며 인증 되었다고 할 수 있음. )
Case2
A --> B
A가 B에게 요청을 보낼 때 B의 "공개"key를 이용해서 암호화함.
중간에서 변조의 위험이 있기 때문에 A의 "개인"Key로 한 번 더 암호화 함.
( B의 "공개"key로 한 번, A의 "개인"key로 한 번 )
이때 B가 A의 "공개"Key로 열어보면, A가 보냈다는 것이 인증이 됨.
그 후 B의 "개인"Key로 내용을 확인할 수 있음
만약 A의 "공개"Key로 열리지 않는다면, A가 보낸것이 아니라고 할 수 있음.
JWT의 구조
JWT토큰은 서명의 용도로 활용한다. 즉 위에서 얘기한 RSA암호화 방식을 사용하는 것이다. 구조는 아래와 같이
Header와 Payload 그리고 Signiture로 구성된다. 아래 구조가 이해가 안 가면 상관없다. 그냥 저렇게 생겼다고 알고만 넘어가면 된다.
Header . Payload . Signiture
x x x x x. y y y y y . z z z z z
header에는 암호화 방식과 타입이 들어가고, 아래와 같다.
{
"alg" : "HS256",
"typ" : "JWT"
}
PayLoad에는 정보를 담을 수 있다. 여기에 id나 name 같은 것들을 넣는 것이다.
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
서명에는 헤더와 페이로드를 암호화해서 넣고, 그 다음에 개인키를 넣어준다.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
Summary 전체 흐름
토큰 발급 과정
1. User가 로그인 요청을 보낸다.
2. 서버에서는 id와 pw를 가지고 우리 회원이 맞는지 확인한다.
3. 맞다면 서버의 secretkey(개인키)와 HMACSHA256을 이용해서 암호화 하고, base64(공개키)를 이용해서 한 번 더 암호화를 진행하여 jwt토큰을 발행한다.
4. 해당 토큰을 user는 localStorage 등에 저장한다.
토큰 이용 과정
1. User는 발급받은 토큰을 헤더에 붙여서 또 다른 요청을 보낸다( ex) 회원정보, 장바구니 등등 )
2. 서버는 해당 토큰을 공개키(base64)로 디코딩 한다 --> 된다면 인증이 된 것임.
3. 디코딩해서 나온 정보를(Header, Payload) 다시 서버의secretkey와 HMACSHA256을 이용해 암호화하여 새로운 토큰을 만든 뒤 user에게 받은 토큰과 비교한다.
4. 두 토큰의 비교를 해서 같다면, 인증된 것이고, 아니라면 서버는 요청에 대한 응답을 반환하지 않는다.
'프로그래밍 > server' 카테고리의 다른 글
| MSA란 무엇인가? (0) | 2023.09.13 |
|---|---|
| OAuth2.0, 인증과 인가 (0) | 2023.09.12 |
| 이미지 호스팅 서비스 Cloudinary with React (0) | 2023.09.04 |
| 세션은 무엇인가? (0) | 2023.07.18 |
| ProxyServer에 대해서 (0) | 2023.07.05 |