Part 1. Access token vs ID token

Nowadays multi-cloud is in every mouth in big companies. The motivations for going multi-cloud are various, it can be for technical flexibility (chose the best tool for the best usage), fault tolerance and redundancy or for reducing the risk of single point of failure. But in any case the problem of security and the federation of identity between services will come pretty quickly.

How we usually share credentials between clouds and why it is bad

The issue is that service identities (Service Account or Service Principal) are not shared between Cloud. A common way to communicate from one Cloud to the other is to create a secret for the service identity and store it on the other Cloud. This way the service account of Cloud A can access Cloud A’s APIs from Cloud B by generating a token from the secret and vice versa. But the extradition of a secret (credential or key) is a security risk. If the secret falls in the wrong hand, the thief would be able to perform requests as the service account and extract sensible data or cause chaos. The solution to this issue might be Identity Federation, but first let’s discuss a bit of theory : how a service account can generate a token to prove its identity ?

Access token vs ID token

“For authentication and authorization, a token is a digital object that contains information about the identity of the principal making the request and what kind of access they are authorized for.”

In the Cloud world (and not only) there are mainly two types of token and associated protocol : Access tokens and ID tokens.

Access Token

Access token are opaque tokens that conform to the OAuth 2.0 framework. They contain authorization information (what the service can do), but not identity information. They are opaque because they are in a proprietary format, applications cannot inspect them.

Note: In some case, access tokens can be decoded (if they are JWT for ex) but do not take this for granted.

ID Token

ID tokens are JSON Web Tokens (JWT) that conform to the OpenID Connect (OIDC) specification. Unlike access tokens, ID tokens can be decoded and inspected by the application. That is why in a multi-cloud world, you will always exchange JWT tokens between Clouds.

The JWT token is composed of 3 parts :

• The header, with information about the algorithm and the token type.
• The payload, with info about the subject (service identity), the issuer (trust authority which signed the token) and more identity info like email, first_name, last_name…
• The signature, generated by a concatenation of a base64 representation of the header and the payload, all encoded by a secret key using the algorithm specified in the header.

All 3 parts are joined with a dot “.” to form the final token.

Ex:

You can decode JWT tokens manually with a base64decode utility or with websites like https://jwt.io/. Decoding the first two parts will give us the following objects:

# header
{
  "alg": "RS256",
  "kid": "b49c5062d890f5ce449e890c88e8dd98c4fee0ab",
  "typ": "JWT"
}

# payload
{
  "aud": "32555940559.apps.googleusercontent.com",
  "azp": "103441981692756022942",
  "exp": 1675978466,
  "iat": 1675974866,
  "iss": "https://accounts.google.com",
  "sub": "103441981692756022942"
}

Here the issuer (iss) which signed the token is https://accounts.google.com and the service account which is represented by the token is the subject (sub) : 103441981692756022942.

Now that we have the basics, how can we exchange an identity token from one Cloud Identity, by impersonating the other Cloud Identity, and protect against secret leaks ? This processus is called identity federation.

Let’s see in details with 2 technical implementations between Azure and Google Cloud Platform and inversely, in the following articles…