Computers, Programming, Technology, Music, Literature

JWT – Quick reference for parameters in JWT claims

leave a comment »

This blog also appears at https://devonblog.com/author/inmaran/

The last blog explored the JWT header and some of the JSON Web Signature (JWS) parameters. This blog focusses on explaining the claims parameters in the JWT payload.

The oversimplified JWT definition:

JWT has three components.

[MetaInformation].[Claims].[Signature]

Sample JWT in the image below:

clip_image002

1. Base64 – The meta data (or header or manifest) that includes how the token is structured, signed, and so on.

2. Base64 – Claims is what provides the actual meaning of the token.

3. Base64 – Signature intends to provide authenticity and integrity.

https://tools.ietf.org/html/rfc7519#section-10.1.2 describes the registered claims for JWT. An identify provider has the flexibility to add claims that are specific for the intended situations.

Exploring JWT payload:

Let’s look at the JWT payload (aka the data aka the claims)

clip_image004

RFC Reference – registered claims are explained at https://tools.ietf.org/html/rfc7519#section-4.1 (JSON Web Token)

Claims can be ‘registered claims’ or ‘custom defined claims’. Registered claims are just a handful, there is only seven of them however in practice this is the section that has user roles, scopes, and also the most important because it contains the actual content of the JWT.

In the above image which represents a JWT token from Azure AD:

aud:

aud implies the intended audience for the token. This is generally the application or the client or the service that the token is intended for. From a security point of view, the audience claims need to be validated to ensure that the token is indeed issued for the particular application and not for some other application. The aud value is typically an application uri.

iss:

iss is the token issuer, that is the secure token service. In delegated authentication scenarios such an OAuth, the protected resource trusts the identify server that issues tokens. So it is imperative for the resource server to verify that the issued token comes from the issuer that the resource / client trusts. The iss value is typically an uri of the issuer.

iat:

iat is the issued at. Typically the EPOCH time at which the token was issued

nbf:

nbf is the not before. Typically the EPOCH time before which the token should not be accepted for processing an authorization for a resource.

exp:

exp is the expiration time (EPOCH time) after which the token should not be accepted for processing an authorization for a resource

aio:

? there seems to be no available from Microsoft on what aio is ? http://lmgtfy.com/?q=azure+ad+claim+aio

appid:

appid is the id of the application as registered in the Azure App registration. In OAuth terms this is the client_id.

appidacr:

appidacr is the Application Authentication Context Class Reference. appidacr indicates how the client was authenticated. For a public client, the value is 0. If client ID and client secret are used, the value is 1. If a client certificate was used for authentication, the value is 2.  Description borrowed directly from – https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-id-and-access-tokens

idp:

idp is the identify provider. Typically same as the value present in the iss claim. The idp value and iss value will be different if the user account is in a different tenant than the issuer. It is worth noting that in Azure AD, the token infrastructure (sts) is shared across multiple tenants.

oid:

oid is the object id that identified the object id as defined in the Azure app registration or the object id of the user in Azure AD

sub:

sub is the subject. Normally the id of the user in the case of ‘authentication code grant’ ‘resource owner password grant’ and ‘implicit grant’ OAUTH flows.

tid:

tid is the tenant identifier of the Azure AD that issued the token. It is worth noting that in Azure AD, the token infrastructure (sts) is shared across multiple tenants.

uti:

? there seems to be no available from Microsoft on what uti is ?

ver:

ver is the JWT token version which at the time of writing is 1.0

Credits and References:

https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-id-and-access-tokens

https://tools.ietf.org/html/rfc7519

https://redthunder.blog/2017/06/08/jwts-jwks-kids-x5ts-oh-my/

https://tools.ietf.org/html/rfc7518

https://tools.ietf.org/html/rfc7515

https://tools.ietf.org/html/rfc7516

Written by gmaran23

October 30, 2018 at 8:48 pm

Posted in jwt, security, token

Tagged with , ,

Leave a comment