Open Authorization

Open Authorization

Open Authentication is using what is called OAuth 2.0. OAuth 2.0 is an industry-standard protocol for authorisation. It allows applications to access resources hosted by other web apps on behalf of a user. See this for more details: OAuth 2.0.

The Open Authentication is using “JSON Web Token”.

Purpose: OAuth 2.0 enables safe sharing of data between different two parties.

1. The application or client requests authorisation to the authorisation server. This is performed through one of the different authorisation flows. For example, a typical OpenID Connect compliant web application will go through the /oauth/authorize endpoint using the authorisation code flow, such as the “Microsoft Identity Platform”.
   
   
2. When the authorisation is granted, the authorisation server returns an access token to the application.
   
   
3. The application uses the access token to access a protected resource (like the Safran Integration API).

Do note that with signed tokens, all the information contained within the token is exposed to users or other parties, even though they are unable to change it. This means you should not put secret information within the token.

JSON Web Token

The Open Authentication is using JSON Web Token (JWT).

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.

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

• Header
• Payload
• Signature

Therefore, a JWT typically looks like the following.
hhhhhh.pppppp.ssssss

Header

The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.

Example, Header:

{
  "alg": "HS256",
  "typ": "JWT"
}

This solution is using the following header parts:

1. alg
   1. This is the encryption algorithm used to sign the JWT. Supported values are:
      1. HS256
         1. Indicate a HMACSHA256 signature. HS256 is a symmetric signing method. This means that the same secret key is used to both create and verify the signature.
      2. RS256
         1. Indicate a RS256 signature. RS256 is an asymmetric encryption method. This differs from a symmetric scheme in that rather than using a single secret key, a pair of separate keys are used to encrypt and decrypt the data.
            
            
2. typ
   1. “JWT” is the only supported value.

Then, this JSON is Base64Url encoded to form the first part of the JWT.

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 data.

This solution is using the following payload parts:

1. aud
   1. This identifies which solution the JWT was intended to. This value must match what is defined in your “application.json” file, for the “jsonwebtoken:audienceclaim” setting.
2. iss
   1. Identification of the Issuer. The “iss” claim is a string that identifies the principal (entity) that issued the JWT. This value must match what is defined in your “application.json” file, for the “jsonwebtoken:issuer” setting.
3. roles
   1. This defines what the calling application can access at the API. See chapter “Access Roles” for more details.

Example, Payload:

{
  "aud": "e8a494f5-f180-4df4-bbc3-762a85c33333",
  "roles": "default.all.read",
  "iss": "https://login.microsoftonline.com/39243333-2c97-4ebf-3333-5c8a0e9b3333/v2.0",
}

The payload is then Base64Url encoded to form the second part of the JSON Web Token.

Signature

To create the signature part, you have to take the encoded header, the encoded payload, a secret, the 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:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret);

The signature is used to verify the message was unmodified along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

JWT location

It is expected that the “JSON Web Token” is part of the “Autorisation” header and that it is located within the header prefixed with “Bearer” of the details sent to the API.

Microsoft Identity Platform

The Microsoft identity platform provides authentication and authorisation services using standards-compliant implementations of OAuth 2.0 and OpenID Connect (OIDC).
Microsoft identity platform: (https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow)

Also see chapter about the configuration of the Microsoft Identity Platform.

Not using Authorisation Server

In case your setup is not using an Authorisation Server, the “JSON Web Token” still needs to be provided. In this case the signature must use the same secret as per configured in the “application.json” file and jsonwebtoken:key”.
See AppSetting example