This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
JSON Web Tokens
JSON Web Tokens

Version management

Difference between version and

At line 1 added 122 lines
!! Overview[1]
[{$pagename}] ([JWT]) is a compact URL-safe means of representing [claims] to be transferred between two parties. The claims in a [{$pagename}] are encoded as a [JavaScript Object Notation] ([JSON]) object that is used as the payload of a [JSON Web Signature] ([JWS]) structure or as the plaintext of a [JSON Web Encryption] ([JWE]) structure, enabling the claims to be digitally signed or MACed and/or encrypted.
JSON Web Token (JWT) is an open standard [RFC 7519] that defines a compact and self-contained way for securely transmitting information between parties as a [JSON Object]. This information can be verified and trusted because it is [digitally signed|JSON Web Signature]. [{$pagename}] can be [signed|JSON Web Signature] using a secret (with HMAC algorithm) or a public/private key pair using RSA.
Let's explain some concepts of this definition further:
* Compact: Because of its size, it can be sent through an URL, POST parameter, or inside an HTTP header. Additionally, due to its size its transmission is fast.
* Self-contained: The payload contains all the required information about the user, to avoid querying the database more than once.
!! The Goal
[{$pagename}] goal is not to hide [data], but to prove your identity ([Authentication]) to the server. Anyone can decode the token, but they can't create fake tokens because that requires the [Private Key]. The server will throw an exception when attempting to decode a fake token, since no one knows your private key (I hope!).
!! When should you use JSON Web Tokens?
There are some scenarios where JSON Web Tokens are useful:
* [JWT Authentication]
* [JWT Data Exchange]
!! [{$pagename}] structure?
[{$pagename}] consist of three parts separated by dots (.), which are:
* Header
* Payload
* Signature
Therefore, a JWT typically looks like the following.
%%prettify
{{{
xxxxx.yyyyy.zzzzz
}}} /%
!! [{$pagename}] Header
Public Header values are Registered within the [JSON Web Signature and Encryption Header Parameters Registry]
The header contains the metadata for the token and at a minimal contains the type of the signature and/or encryption algorithm:
* "[typ]" - the type of the token, which is [JWT]
* "[alg]" - the hashing algorithm such as [HS256].
* "[cty]" - Header Parameter defined by [JSON Web Signature] and [JSON Web Encryption] is used by this specification to convey structural information about the JWT.
For [example]:
%%prettify
{{{
{
"typ": "JWT"
"alg": "HS256",
"cty": "arbitrary"
}
}}} /%
Then, this JSON is [Base64]Url encoded to form the first part of the JWT.
!! [{$pagename}] Payload
The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional [metadata].
There are three types of [claims]:
* Reserved claims: These are a set of predefined claims, which are not mandatory but recommended, thought to provide a set of useful, interoperable claims. Some of them are:
** [iss] ([issuer])
** [exp] (expiration time)
** [sub] (subject)
** [aud] (audience)
** others.
* [Public claims|JSON Web Token Claims]: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the [IANA JSON Web Token Registry|JSON Web Token Claims] or be defined as a URI that contains a collision resistant [namespace].
* Private claims: These are the custom claims created to share information between parties that agree on using them.
!! [JSON Web Token Claims]
[JSON Web Token Claims] are registered names.
%%information
Notice that the claim names are only three characters long as JWT is meant to be compact.
%%
An [example] of payload could be:
%%prettify
{{{
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
}}} /%
The payload is then [Base64]Url encoded to form the second part of the [{$pagename}]
!! [{$pagename}] [Signature|JSON Web Signature]
To create the [signature|JSON Web Signature] part you have to take the:
* encoded header
* encoded payload
* a secret
* algorithm specified in the header
and sign that.
For [example] if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way.
%%prettify
{{{
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
}}} /%
The [signature|JSON Web Signature] provides the same assurances as any [Digital Signature]
!! [{$pagename}] Profiles
THere are some [{$pagename}] "Profiles" that more narrowly define the contents of [{$pagename}].
* [CBOR Web Token (CWT)|CBOR Web Token]
!! How to Secure [{$pagename}][3]
There are a lot of libraries out there that will help you create and verify [{$pagename}], but when using JWT’s there still some things that you can do to limit your security risk.
__First Always__ verify the [signature|JSON Web Signature] before you trust any information in the JWT. This should be a given, but we have recently seen security vulnerabilities in other company’s JWT frameworks. One gotcha that we have seen recently is around the JWT spec that allows you to set signature algorithm to ‘none’. This should be ignored if you expect the JWT to be signed. Put another way, if you are passing a secret signing key to the method that verifies the signature and the signature algorithm is set to ‘none’, it should fail verification.
__Second_ Secure the secret signing key used for calculating and verifying the signature. The secret signing key should only be accessible by the issuer and the consumer, it should not be accessible outside of these two parties.
__Third__ Do not use any sensitive data in a JWT that is not [encrypted|JSON Web Encryption]. JWT tokens are usually signed to protect against manipulation (not encrypted) so the data in the claims can be easily decoded and read. For example, you should not include a user’s address in a JWT. You could provide a link to the user’s record or some other identifier [that is opaque|By-reference] and have your application look up the information. If you do need to store sensitive information in a JWT, check out [JSON Web Encryption] ([JWE]).
If you worried about replay attacks, include a [nonce] ([jti claim]), expiration time ([exp claim]), and creation time ([iat claim]) in the [claims].
!! [JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants]
[JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants] is described in [RFC 7523]
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Introduction to JSON Web Tokens|https://jwt.io/introduction//|target='_blank'] - based on information obtained 2016-02-12-
* [#2] - [RFC 7519|https://tools.ietf.org/html/rfc7519|target='_blank'] - based on data observed:2015-05-18
* [#3] - [Use JWT the Right Way|https://stormpath.com/blog/jwt-the-right-way/|target='_blank'] - based on data observed:2016-02-16
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop