A JSON Web Token (JWT) is a JSON-based access token standardized according to RFC. The JWT enables the exchange of verifiable claims. It is typically used to exchange a user’s identity between an identity provider and a service provider in a third-party system. JWTs are particularly suitable for implementing “stateless sessions”, as all authentication-relevant information can be transmitted in the token and the session does not have to be stored additionally on a server.
Advantage of JWT is that it is stateless. No data needs to be persistent to authenticate any user. Also, we do not need any other source to verify the user.
Construction of a JSON Web Token (JWT)
A JWT consists of three parts: the header, payload, and signature.
---
The header is a JSON element that describes what type of token it is and which signature method is used.
typ: Type describes the IANA media type of the token. This value is always used to describe the media type. JWTapplication/jwtcty: Content Type field is required if the JWT contains another JWT as a payload. In this case, it is set to . Otherwise, this field should be omitted.alg: Algorithm Describes which signature method is used. The signature method is usually HMAC with SHA-256 or RSA with SHA-256. It is possible not to use a signature, but this is not recommended. The possible values are standardized by JSON Web Encryption (JWE) according to RFC 7516.
The typ and alg are object keys with different values and give us the type of the header of this information packet and the encryption algorithm used.
Example of header:
1 2 3 4 | { "typ":"JWT", "alg":"HS256" } |
The payload is then Base64Url encoded to form the first part of the JSON Web Token.
The payload is a JSON element that describes the claims.
iss: The issuer of the tokensub: Defines the subject to which the claims apply. The field defines for whom or what the claims are made. subaud: The destination domain (audience) for which the token was issued.exp: The expiration date of the token in Unix timenbf: The Unix time from which the token is valid.iat: The Unix time at which the token was issued.jti: A unique case-sensitive string that uniquely identifies the token. This can be used to prevent the token from being replicated. This can be a counted number, a GUID or a hash value. If the token recipient receives a token from multiple issuers, the JWT ID may not be unique. By combining the issuer (iss) and the JWT ID (jti), this can become unique again.
Furthermore, public claims are defined by the IANA. In addition, the issuer of the JWT can also use a private claim-defined URI, which is not standardized. For example, an ontology such as Dublin Core or FOAF can be used here.
Example:
1 2 3 4 5 6 | { "userId":"n09t85ae-69da", "iss": "https://thecustomizewindows.com/", "sub": "auth/hash-code", "exp": 153452683 } |
The payload is then Base64Url encoded to form the second part of the JSON Web Token.
Securely validates the token. The structure of the signature is defined by JSON Web Signature (JWS), a standard standardized according to RFC 7515. The signature is generated by hashing the header and payload in Base64 encoded format with the specified hash method.
For example, if we want to use the HMAC SHA256 algorithm, the signature will be created in the following way:
1 2 3 4 | HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) |
The header, payload and signature are each encoded with a Base64 URL and separated by a period. A JWT token can look like this:
1 | var jwt = base64UrlEncode(header) + "." + base64UrlEncode(payload) + "." + base64UrlEncode(hash) |
The output will look like this:
1 | eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzY290Y2guaW8iLCJleHAiOjEzMDA4MTkzODAsIm5hbWUiOiJDaHJpcyBTZXZpbGxlamEiLCJhZG1pbiI6dHJ1ZX0.03f329983b86f7d9a9f5fef85305880101d5e302afafa20154d094b229f75773 |
You’ll get debugger, parser, libraries here: jwt.io/#debugger-io
You’ll get ready to implement projects on GitHub in most of the common languages, such as C++, Java, PHP, Python and so on. For exapmle:
1 | https://github.com/kelvinmo/simplejwt |
The JWT can be transmitted in the URL or in the HTTP header.
1 | http://example.com/path?jwt_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9… |
There are two ways to transfer in the HTTP header: the authorization field or the cookie field.
in the Authorization field as a bearer token:
1 | Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9… |
in the cookie field:
1 | Cookie: token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9… |
It works with CORS, but requires implementation in JavaScript.
A Security Event Token (SET) extends the JWT standard with the claim, which records a list of security-relevant events. These tokens have a digital timestamp and unlimited validity. A SET payload can look like this:
1 2 3 4 5 6 7 8 9 10 11 | { "iss": "https://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "iat": 1471566154, "jti": "bWJq", "sid": "08a5019c-17e1-4977-8f42-65a12843ea02", "events": { "http://schemas.openid.net/event/backchannel-logout": {} } } |
Conclusion
JWT is a great solution, but it works best in certain scenarios. JWT is best suited when communicating API to API and may be in IoT. It is risky to use JWT for web-based login procedures (requires a lot of steps to mitigate the probable weak points).
Tagged With JSON веб-токены