JSON Web Token (JWT, pronounced , same as the word "jot") is a proposed Internet standard for creating data with optional signature and/or optional encryption whose payload holds JSON that asserts some number of claims. The tokens are signed either using a private secret or a public/private key.

For example, a server could generate a token that has the claim "logged in as administrator" and provide that to a client. The client could then use that token to prove that it is logged in as admin. The tokens can be signed by one party's private key (usually the server's) so that any party can subsequently verify whether or not the token is legitimate. If the other party, by some suitable and trustworthy means, is in possession of the corresponding public key, they too are able to verify the token's legitimacy. The tokens are designed to be compact, URL-safe, and usable especially in a web-browser single-sign-on (SSO) context. JWT claims can typically be used to pass identity of authenticated users between an identity provider and a service provider, or any other type of claims as required by business processes.

JWT relies on other JSON-based standards: JSON Web Signature and JSON Web Encryption.

Structure
Header
Identifies which algorithm is used to generate the signature HS256 indicates that this token is signed using HMAC-SHA256.
Typical cryptographic algorithms used are HMAC with SHA-256 (HS256) and RSA signature with SHA-256 (RS256). JWA (JSON Web Algorithms) RFC 7518 introduces many more for both authentication and encryption.
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
Contains a set of claims. The JWT specification defines seven Registered Claim Names, which are the standard fields commonly included in tokens. Custom claims are usually also included, depending on the purpose of the token.
This example has the standard Issued At Time claim (iat) and a custom claim (loggedInAs).
{
  "loggedInAs": "admin",
  "iat": 1422779638
}
Signature
Securely validates the token. The signature is calculated by encoding the header and payload using Base64url Encoding  and concatenating the two together with a period separator. That string is then run through the cryptographic algorithm specified in the header. This example uses HMAC-SHA256 with a shared secret (public key algorithms are also defined). The Base64url Encoding is similar to base64, but uses different non-alphanumeric characters and omits padding.
HMAC_SHA256(
  secret,
  base64urlEncoding(header) + '.' +
  base64urlEncoding(payload)
)

The three parts are encoded separately using Base64url Encoding , and concatenated using periods to produce the JWT:
const token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)

The above data and the secret of "secretkey" creates the token:

This resulting token can be easily passed into HTML and HTTP.

Use 
In authentication, when the user successfully logs in using their credentials, a JSON Web Token will be returned and must be saved locally (typically in local or session storage, but cookies can also be used), instead of the traditional approach of creating a session in the server and returning a cookie. For unattended processes the client may also authenticate directly by generating and signing its own JWT with a pre-shared secret and pass it to a OAuth compliant service like so:POST /oauth2/token
Content-type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=eyJhb...If the client passes a valid JWT assertion the server will generate an access_token valid for making calls to the application and pass it back to the client:{
  "access_token": "eyJhb...",
  "token_type": "Bearer",
  "expires_in": 3600
}When the client wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization HTTP header using the Bearer schema. The content of the header might look like the following:
 Authorization: Bearer eyJhbGci...<snip>...yu5CSpyHI
This is a stateless authentication mechanism as the user state is never saved in server memory. The server's protected routes will check for a valid JWT in the Authorization header, and if it is present, the user will be allowed to access protected resources. As JWTs are self-contained, all the necessary information is there, reducing the need to query the database multiple times.

Standard fields

Implementations 
JWT implementations exist for many languages and frameworks, including but not limited to:

.NET (C# VB.Net etc.)
C
Clojure
Common Lisp
 Dart
Elixir
 Erlang
Go
Haskell
Java
JavaScript
Lua
 Node.js
OCaml
Perl
PHP
PL/SQL
PowerShell
Python
Racket
Raku
Ruby
Rust
Scala
Swift

Vulnerabilities
JSON web tokens may contain session state. But if project requirements allow session invalidation before JWT expiration, services can no longer trust token assertions by the token alone. To validate that the session stored in the token is not revoked, token assertions must be checked against a data store. This renders the tokens no longer stateless, undermining the primary advantage of JWTs.

Security consultant Tim McLean reported vulnerabilities in some JWT libraries that used the alg field to incorrectly validate tokens, most commonly by accepting a alg=none token. While these vulnerabilities were patched, McLean suggested deprecating the alg field altogether to prevent similar implementation confusion. Still, new alg=none vulnerabilities are still being found in the wild, with four CVEs filed in the 2018-2021 period having this cause.

With proper design, developers can address algorithm vulnerabilities by taking precautions:

 Never let the JWT header alone drive verification
 Know the algorithms (avoid depending on the  field alone)
 Use an appropriate key size
Several JWT libraries were found to be vulnerable to an invalid Ecliptic-curve attack in 2017.

Some have argued that JSON web tokens are difficult to use securely due to the many different encryption algorithms and options available in the standard, and that alternate standards should be used instead.

See also
 API key
 Access token
 Basic access authentication
 Digest access authentication
 Claims-based identity
 HTTP header
 Concise Binary Object Representation (CBOR)

References

 
 jwt.io – specialized website about JWT with tools and documentation, maintained by Auth0

Computer access control
Identity management
Federated identity
Identity management systems
Metadata standards
JSON
JSON 웹 토큰(JSON Web Token, JWT, "jot”)은 선택적 서명 및 선택적 암호화를 사용하여 데이터를 만들기 위한 인터넷 표준으로, 페이로드는 몇몇 클레임(claim) 표명(assert)을 처리하는 JSON을 보관하고 있다. 토큰은 비공개 시크릿 키 또는 공개/비공개 키를 사용하여 서명된다. 이를테면 서버는 "관리자로 로그인됨"이라는 클레임이 있는 토큰을 생성하여 이를 클라이언트에 제공할 수 있다. 그러면 클라이언트는 해당 토큰을 사용하여 관리자로 로그인됨을 증명한다. 이 토큰들은 한쪽 당사자의 비공개 키(일반적으로 서버의 비공개 키)에 의해 서명이 가능하며 이로써 해당 당사자는 최종적으로 토큰이 적법한지를 확인할 수 있다. 일부 적절하고 신뢰할만한 수단을 통해 다른 당사자가 상응하는 공개키를 소유하는 경우 이 경우 또한 토큰의 적법성 확인이 가능하다. 토큰은 크기가 작고 URL 안전으로 설계되어 있으며 특히 웹 브라우저 통합 인증(SSO) 컨텍스트에 유용하다.
JWT 클레임은 아이덴티티 제공자와 서비스 제공자 간(또는 비즈니스 프로세스에 필요한 클레임)의 인가된 사용자의 아이덴티티를 전달하기 위해 보통 사용할 수 있다.

JWT는 다른 JSON 기반 표준에 의존한다: JSON 웹 시그너처 및 JSON 웹 암호화.

구조 

이 세 부분은 Base64url 인코딩을 사용하여 별도로 인코딩되며 JWT 생성을 위해 점(.)을 사용하여 연결된다:
const token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)

위 데이터와 "secretkey" 시크릿은 토큰을 생성한다:

이 결과가 되는 토큰은 HTML과 HTTP로 쉽게 파싱이 가능하다.

이용 
인증의 경우 사용자가 성공적으로 자신들의 자격 정보를 사용하여 로그인하면 서버에 세션을 만들고 쿠키를 반환하는 전통적인 접근방식 대신 JSON 웹 토큰이 반환되며 로컬(일반적으로 로컬 또는 세션 스토리지. 쿠키를 사용할 수도 있음)에 저장되어야 한다. 부재 중인 프로세스의 경우 클라이언트는 미리 공유된 시크릿으로 자신만의 JWT를 생성하고 서명하고 이를 OAuth를 준수하는 서비스에 전달함으로써 다음과 같이 직접 인증을 수행할 수도 있다.:POST /oauth2/token?
Content-type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=eyJhb...
클라이언트가 유효한 JWT 표명을 전달하면 서버는 애플리케이션의 요청을 하기 위한 access_token을 생성하고 클라이언트에 이를 전달해주게 된다:{
  "access_token": "eyJhb...",
  "token_type": "Bearer",
  "expires_in": 3600
}
클라이언트가 보호된 루트나 자원에 접근하고 싶은 경우 사용자 에이전트는 일반적으로 Bearer 스키마를 사용하여 Authorization 헤더 안에 JWT를 보내야 한다. 헤더의 내용은 다음과 같을 수 있다:
 Authorization: Bearer eyJhbGci...<snip>...yu5CSpyHI
이것은 무상태 인증 매커니즘으로서, 사용자의 상태는 서버 메모리에 전혀 저장되지 않는다. 서버의 보호된 루트는 Authorization 헤더 내의 유효한 JWT를 검사하며 이것이 존재하는 경우 사용자는 보호된 자원으로의 접근이 허가된다. JWT가 자가 수용적(self-contained)이므로 필요한 모든 정보는 JWT에 있으며 데이터베이스를 여러 번 조회할 필요를 줄여준다.

구현체 
JWT 구현체는 수많은 언어와 프레임워크용으로 존재한다:

 .NET (C# VB.Net 등)
 C
 클로저 (프로그래밍 언어)
 커먼 리스프
 Dart
 Elixir
 Erlang
 Go
 하스켈
 자바
 자바스크립트
 루아
 Node.js
 OCaml
 펄
 PHP
 PL/SQL
 파워셸
 파이썬
 래킷
 라쿠
 루비
 러스트
 스칼라
 스위프트

취약성 
JSON 웹 토큰은 세션 상태를 포함할 수 있다. 그러나 프로젝트 요건이 JWT 기간 만료 이전에 세션 무효화를 허용하는 경우 서비스는 더 이상 토큰만으로 토큰 표명(token assertion)을 신뢰할 수 없다. 토큰에 저장된 세션이 폐지되지 않음을 확인하기 위해 토큰 표명은 데이터 스토어에 대해 검사되어야 한다. 이렇게 하면 토큰이 더 이상 무상태가 아니게 됨으로써 JWT의 주된 이점이 약화되는 결과를 낳는다.

보안 상담가 팀 메클레인(Tim McLean)은 alg 필드를 사용하여 토큰의 유효성을 잘못 확인하는 일부 JWT 라이브러리의 취약성을 보고하였다. 이 취약점들이 패치가 되었으나 메클레인은 비슷한 구현체 혼동을 예방하기 위해 alg 필드를 구식 처리하는 것을 제안하였다.

적절히 설계할 경우 개발자는 일부 주의를 기울이면 알고리즘 취약성을 해결할 수 있다:

 JWT 헤더만으로 유효성을 확인하지 않을 것
 알고리즘을 인지할 것
 적절한 키 크기를 사용할 것

소프트웨어 보안 설계자 커트 로다머(Kurt Rodarmer)는 암호화 서명 키와 관련한 JWT의 추가적인 설계적 취약성, 그리고 라이브러리의 JSON 파서가 공격에 노출되는 중대한 취약성을 지적한다. 이는 토큰 헤더를 표현할 때 JSON을 선택하는데 따른 직접적인 결과이며 완화가 어렵다.

각주

외부 링크 
 
 jwt.io – specialized website about JWT with tools and documentation, maintained by Auth0
 Spring Boot JWT Auth – Integrating JWT authentication with Spring framework
 JWT Security – JWT Security e-Book PDF (Polish language)
 Why do we need JWT in the modern web - a detailed article on the topic with some historical considerations

컴퓨터 접근 제어
아이덴티티 관리
아이덴티티 관리 시스템
메타데이터 표준
JSON