JWT.IO
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
jwt.io
JWT(JSON Web Token)
당사자 간에 정보를 JSON 개체로 안전하게 전송하기 위한 간결하고 독립적인 방법을 정의하는 개방형 표준( RFC 7519 )이다.
RFC 7519: JSON Web Token (JWT)
www.rfc-editor.org
JWT를 암호화하여 당사자 간에 비밀성을 제공할 수도 있지만 서명된 토큰으로 사용할 수도 있다.
구조
- Header
- Payload
- Signature
xxxxx.yyyyy.zzzzz
Header

dnl JSON은 Base64Url로 인코딩 되어 JWT의 첫 번째 부분을 구성한다. Base64는 암호화와 복호화를 할 수 있는 암호이다.
Payload
- Registered claims
- Public claims
- Private claims
우리는 Private claims에 유저 id 등을 넣어볼 것이다.

Signature

서명 부분에는 우리가 만들었던 header, payload, 그리고 나만 알고 있는 key를 암호화한다.
요청 과정
클라이언트가 로그인을 시도하면 서버는 header, payload, signature를 만든다. header에는 HS256으로 서명을 했다는 정보가, payload에는 {username : ssar}, signature에는 (header + payload + 서버만 알고 있는 key) 이것을 HS256으로 암호화한다.
H는 HMAC을 의미하는데 HMAC은 시크릿키를 포함한 암호화 방식이다. 서버만 알고 있는 key가 시크릿 키이므로 signature는 HMAC 암호화 방식으로 암호화한 것이다.
S256은 SHA256을 의미하는데, SHA256은 해시 알고리즘이다.
header, payload, signature 각각을 Base64로 인코딩하여 클라이언트에게 돌려준다. 클라이언트는 이 정보를 브라우저의 로컬 스토리지 같은 영역이 있는데 여기에 저장한다.

이제 클라이언트가 자신의 개인정보를 요청할 때 JWT를 함께 보낸다. 서버는 받은 JWT가 신뢰할 수 있는지 검증한다. JWT의 데이터가 무엇인지 아는 것이 중요한 게 아니라 유효한지를 확인하는 것이 중요하다.
받은 signature의 정보가 ABC5라고 가정했을 때, 서버는 header+payload+서버의 시크릿키를 HS256으로 암호화를 해본다. 그 결과가 ABC5와 같은 지 비교한다. 같다면 인증이 되는 것이다. 요청한 개인정보는 payload의 username으로 DB에서 select 해서 돌려주면 된다.
HS256을 사용하지 않고 RSA를 사용한다면
header에는 RSA
payload에는 username:ssar
signature에는 header+payload
이렇게 구성된다. secret은 필요가 없다. 서버가 개인키로 header와 payload를 암호화해서 signature를 만들고 클라이언트에게 준다. 클라이언트가 이 토큰을 가지고 서버에 요청하면 서버는 검증 시에 공개키로 signature를 확인하면 된다.
RSA와 HS256 둘 중 하나로 하면 되는데 보통 HS256을 더 많이 사용한다.
'Spring Security' 카테고리의 다른 글
[웹 보안] RSA (0) | 2023.03.27 |
---|---|
[웹 보안] TCP (0) | 2023.03.27 |
[웹 보안] 세션 (0) | 2023.03.27 |
[OAuth] 네이버 로그인 (0) | 2023.03.27 |
[OAuth] 페이스북 로그인 (0) | 2023.03.26 |
JWT.IO
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
jwt.io
JWT(JSON Web Token)
당사자 간에 정보를 JSON 개체로 안전하게 전송하기 위한 간결하고 독립적인 방법을 정의하는 개방형 표준( RFC 7519 )이다.
RFC 7519: JSON Web Token (JWT)
www.rfc-editor.org
JWT를 암호화하여 당사자 간에 비밀성을 제공할 수도 있지만 서명된 토큰으로 사용할 수도 있다.
구조
- Header
- Payload
- Signature
xxxxx.yyyyy.zzzzz
Header

dnl JSON은 Base64Url로 인코딩 되어 JWT의 첫 번째 부분을 구성한다. Base64는 암호화와 복호화를 할 수 있는 암호이다.
Payload
- Registered claims
- Public claims
- Private claims
우리는 Private claims에 유저 id 등을 넣어볼 것이다.

Signature

서명 부분에는 우리가 만들었던 header, payload, 그리고 나만 알고 있는 key를 암호화한다.
요청 과정
클라이언트가 로그인을 시도하면 서버는 header, payload, signature를 만든다. header에는 HS256으로 서명을 했다는 정보가, payload에는 {username : ssar}, signature에는 (header + payload + 서버만 알고 있는 key) 이것을 HS256으로 암호화한다.
H는 HMAC을 의미하는데 HMAC은 시크릿키를 포함한 암호화 방식이다. 서버만 알고 있는 key가 시크릿 키이므로 signature는 HMAC 암호화 방식으로 암호화한 것이다.
S256은 SHA256을 의미하는데, SHA256은 해시 알고리즘이다.
header, payload, signature 각각을 Base64로 인코딩하여 클라이언트에게 돌려준다. 클라이언트는 이 정보를 브라우저의 로컬 스토리지 같은 영역이 있는데 여기에 저장한다.

이제 클라이언트가 자신의 개인정보를 요청할 때 JWT를 함께 보낸다. 서버는 받은 JWT가 신뢰할 수 있는지 검증한다. JWT의 데이터가 무엇인지 아는 것이 중요한 게 아니라 유효한지를 확인하는 것이 중요하다.
받은 signature의 정보가 ABC5라고 가정했을 때, 서버는 header+payload+서버의 시크릿키를 HS256으로 암호화를 해본다. 그 결과가 ABC5와 같은 지 비교한다. 같다면 인증이 되는 것이다. 요청한 개인정보는 payload의 username으로 DB에서 select 해서 돌려주면 된다.
HS256을 사용하지 않고 RSA를 사용한다면
header에는 RSA
payload에는 username:ssar
signature에는 header+payload
이렇게 구성된다. secret은 필요가 없다. 서버가 개인키로 header와 payload를 암호화해서 signature를 만들고 클라이언트에게 준다. 클라이언트가 이 토큰을 가지고 서버에 요청하면 서버는 검증 시에 공개키로 signature를 확인하면 된다.
RSA와 HS256 둘 중 하나로 하면 되는데 보통 HS256을 더 많이 사용한다.
'Spring Security' 카테고리의 다른 글
[웹 보안] RSA (0) | 2023.03.27 |
---|---|
[웹 보안] TCP (0) | 2023.03.27 |
[웹 보안] 세션 (0) | 2023.03.27 |
[OAuth] 네이버 로그인 (0) | 2023.03.27 |
[OAuth] 페이스북 로그인 (0) | 2023.03.26 |