Moving forward on the IT world

JSON WEB TOKEN

xxx.yyy.zzz

xxx => header consist in 2 parts : the type of the toker which is JWT and the signing algorithm being used, such as HMAC SHA256 or RSA.

Ex:

 {

“alg”: “HS256”,

“typ”; “JWT”

}

And then this JSON is Base64Url encoded to form the first part of the the JWT

yyy => payload contains the claims. Claims are statement about an entity (tipically, the user and additional data. 3 types of claims registered, public and private claims

• Registered claims are a set of predefined claims which are not mandatory but recommended. Iss(issuer),exp(expiration time), sub(subject), aud(audience)
• Public claims:  these can be defined at will by those using JWT’s but to avoid collision they should be defined in the iana json web token tegistry or be defined as UTI that contains a collision resistant namespaces
• Private claims : these are custom claims created to share information between parties that gree using them

{

“sub”: 1234567,

“name” : John Doe,

“admin”: true

}

ZZZ => Signature to create signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that

HMACSHA256(

base64UrlEncode(header) +  “.” +

base64UrlEncode(payload),

secret)

Application(Client) => 1) authorization Server 2) => Application (Client) => 3) API resource server

1. The client application requests authorization to the authorization server. This is performed through one of the different authorization flows hereunder:

The Authorization Code Flow goes through the following steps.

• Client prepares an Authentication Request containing the desired request parameters.
• Client sends the request to the Authorization Server.
• Authorization Server Authenticates the End-User.
• Authorization Server obtains End-User Consent/Authorization.
• Authorization Server sends the End-User back to the Client with an Authorization Code.
• Client requests a response using the Authorization Code at the Token Endpoint.
• Client receives a response that contains an ID Token and Access Token in the response body.
• Client validates the ID token and retrieves the End-User’s Subject Identifier
• When the authorization is granted the authorization server returns an access token to the application.

• The application uses the access token to access a protected resource (like an API)

Information in signed tokens are exposed to users and or other parties. Even though they can’t change it. Secret information shouldn’t be stored within the token