OAuth 2.0: Secure server to server application connections with GCP as third party OAuth provider

Product Information

• IBM API Connect V2018.4.1.x – v5c

Requirements

• Developer account on APIC (used version v2018.4.1.x)
• Google service account.

Case: oAuth conncection GCP

In this blog we will take a look on how we can create a secure connection between IBM APIC v2018 and an API with Google Cloud Platform (GCP) as third party oAuth provider.

The Google OAuth 2.0 system supports server-to-server interactions, example given: API Gateway and a Google service. To be able to do this, we need a service account. A service account is an account that belongs to an application (in our case to the API Gateway). Service account info used during this setup will be blurred as these are company specific. The documentation pages of IBM and Google are provided at the references section (at the bottom).

I will explain the setup and how I tested the different steps. Following schema already gives a basic view of the steps that we are going to take.

1. Request an authorization token from GCP using a JWT
2. Verify the response from GCP contained the authorization token and not an error message
3. Take the authorization token from the response received from GCP to build the request for the API you need to call.

Prepare an authorized call

Using the service account, you can prepare your authorized call to an API on the GCP. This will be done in three steps:

• Create a JSON Web Token (JWT) containing the required claims and signatures (mind we do not encode)
• Exchange your JWT for an authorization token (id-token) from GCP
• Use the id-token the authorize your call with the API on the GCP.

This sequence diagram explains visualizes the three steps :

Following screenshot shows the policies used in an assemble to get an authorization token. This can be part of your API or it can be a reusable and dedicate API you use in other API’s to provide you with an authorization token.

API assembly

Next we will discuss all configuration done for each policy in detail.

Setup

Create needed variables (set-jwt-variables)

To create a correct JWT for the GCP, I created following parameters:

• iss-claim: The email address of the service account.
• aud-claim : A descriptor of the intended target of the assertion. In case for an API authorized by GCP, this value is ‘https://oauth2.googleapis.com/token’
• priv-claim: Variable to provide an extra required claim, in our case it is used for a scope-claim or a target-audience
• sign-jwt: A Crypto object containing the keys to sign the header and claims

Tip: If you want to make a dedicated API for this, you can pass these variables as header parameters to the API.

In the setup shown in the screenshot above, we are using a set-variables policy called ‘set-jwt-variables’ to create and declare these variables.

Following screenshot show how the set-jwt-variables policy has been filled in (with dummy data)

Generate JWT

Now we can complete the ‘jwt-generate’ policy. Following screenshot show how I completed the policy.
Remark: I only added the lines where I added/changed values.

• generated.jwt: this runtime variable will be used to store the result. I will need it in a follow-up policy. This will not be the value for my Bearer token, but I will use this token to exchange it for my bearer token!
• Issuer Claim, Audience Claim and Private Claim where configure in the previous set-variable policy
• Cryptographic Algorithm must be RS256. This is defined by the Google docs:
  

• Sign Crypto Object is the crypto object containing the certificate(s) and key(s) required to sign the JWT. Typically these are added using a keystore and TLS profile in the API Manager
  

Test your JWT

The easiest two ways to test if your token is valid is by doing the next:

1. Click the test button in your assemble but don’t add a proxy or invoke, only your jwt-variables and jwt-generate policies.
   

2. Publish your API
   • Create an API containing only your set-jwt-variables and jwt-generate policies.
   • publish this API and see your result.
   • It should look like:
     • syntax: {header}.{claim}.{signature}  (blurred example below)

Validate your token

Go to: https://jwt.io/

get-id-token-request

You can find your JWT in the runtime variable called ‘generated.jwt’ (this was configured in the jwt-generate policy (see above in the screenshots). Next step is to use this value and exchange it for an authorization token (Bearer token). The following screenshots show you the variables set:

get-id-token

Now that the message is prepared, we need to send the request to GCP to exchange the token. In this setup, there is only one config needed to be provided in the invoke policy. We need to add the url of the GCP exposing the API. We defined a property called ‘gcp-auth’ which as the value: https://oauth2.googleapis.com/token‘

Verify if you receive an authorization token.

The result of the test must look like:

set-authorization

Final step is to set the result in the correct header ‘message.headers.Authorization’. I’ve used a gateway script and I’ve added following piece of code:

Result

Your header now contains a by Google authorized token to communicate with the

References

• GCP: Google service accounts
• GCP: Using OAuth 2.0 for Server to Server Applications
• GCP: Authenticating service-to-service
• IBM APIC: OAuth responses

Written by: Niki Heyligen

Need some help with OAuth and API Connect for your organization?