JWT(JSON Web Token)은 JSON 객체로 정보를 암호화해 전달해준다.
구조 |
Header, Payload, Signature의 세 부분으로 이루어져 있고 .으로 구분된 xxxxx.yyyyy.zzzzz의 형식이다.
- Header
{
"alg": "HS256",
"typ": "JWT"
}
토큰의 타입 (일반적으로 JWT)과 JWT가 토큰에 서명할 때 사용하는 알고리즘(RS256, HS256)의 종류로 이루어져 있다.
RS256은 SHA-256 함수를 이용한 RSA 암호화 방식을 의미한다. 즉 공개 키 암호화이다.
HS256은 비밀 키 암호화이다.
- Payload
key-value의 한 쌍을 claim이라고 하는데, Payload에는 이런 claim들이 들어있다.
- Registered claims
iss, exp, sub, aud 처럼 알파벳 세 글자로 이루어진 미리 정의된 key들이다. 토큰에 대한 정보를 담고 있다. - Public claims
Public claims는 사용자 마음대로 정의할 수 있다. 대신 key가 충돌되면 안되기 때문에 IANA JSON 웹 토큰 레지스트리에 정의하거나 URI로 지어야 한다. - Private claims
주로 클라이언트와 서버 간에 전달해야 하는 정보들은 여기에 들어간다.
{
"sub": "1234567890",
"https://r4bb1t.tistory.com/tokki_is_r4bb1t": true,
"username": "r4bb1t",
}
"sub": "1234567890"는 Registered claims로, 토큰의 제목을 나타내고
"r4bb1t.tistory.com/tokki_is_r4bb1t": true는 key가 URI로 작성된 Public claims다.
"username": "r4bb1t"는 위의 둘 중 어느 것에도 해당이 안 되는 Private claims다.
- Signature
인코딩된 헤더와 페이로드 값을 Secret key를 이용해 헤더에 지정된 알고리즘으로 해싱한 결과가 Signature 부분이다. 그러니까 이 부분을 이용해 앞 부분 정보가 변조되지 않았는지 검증하는 것임.
이용 |
쿠키와 세션을 이용해 인증을 관리할 때, 서버에서는 세션의 상태를 항상 가지고 있어야 한다.
반면 JWT 등의 토큰 기반 인증을 이용하면 서버에서는 토큰이 유효한지 검사만 하면 되므로 부담이 줄게 된다.
예를 들어 로그인 시에, 클라이언트에서 ID, Password로 로그인 요청을 보내면 서버에서 확인 후 토큰을 발급한다.
이 토큰이 "이 클라이언트가 로그인에 성공했음을 증명함" 증명서같은 역할을 하는 것이다.
그 이후에 클라이언트에서 요청을 할 때는 요청 헤더에 발급받은 토큰을 붙여서 보내면 서버에서는 해당 토큰이 유효한지만 검사하면 정보를 확인할 수 있다.
토큰 내에 클라이언트에 관한 정보가 다 들어있기 때문에, 서버에서는 클라이언트 각각에 대한 로그인 정보를 계속 가지고 있지 않아도 된다.
참고 문서 |
'Web > Backend' 카테고리의 다른 글
[Strapi] Strapi 설치부터 배포까지 (1) | 2022.08.23 |
---|---|
[GCP] 구글 클라우드 플랫폼에 Nginx로 리액트 프로젝트 배포하기 (2) | 2020.11.29 |
[GCP] 구글 클라우드 DNS에 도메인 연결하기 (2) | 2020.07.20 |
[GCS] 구글 클라우드 스토리지(GCS)로 파일 업로드 후 접근 URL 생성하기 (3) | 2020.06.01 |
[GCS] [번역] 브라우저에서 구글 클라우드 스토리지(GCS)로 파일 업로드하기 (0) | 2020.06.01 |
댓글