OAuth was built for authorization and cared most about the permissions and scopes of the protected resources. These permissions were then assigned to a client on a resource owner’s behalf. OAuth’s fundamental limitation was that it did not provide any standard way for the client to fetch any meta-information about the logged-in user. The client application was oblivious to information such as the resource owner’s email ID, name, account creation date, last logged-in date, and profile picture. The OIDC standard was built on top of OAuth to solve some of these limitations of OAuth.

Most of the steps related to enhancing a resource’s security using OIDC remain identical to the OAuth implementation that you just covered in detail. Some of those steps (OAuth) are enhanced to add OIDC capability to an API. This section will cover those changes to the OAuth configuration. These changes to the OAuth flow to accommodate OIDC can be classified into two main categories: OAuth provider configuration changes and OAuth flow changes. Let’s take a quick look at these:

• OAuth provider configuration changes involve the following:
  • Enabling OIDC capability in the provider.
  • Providing a security object to sign the ID token. The ID token is the resource owner’s profile token. This helps the client in ensuring the integrity of the ID token that is returned by the authorization server.
• OAuth flow changes have the following effect:
  • Adding OIDC scope to the Fetch Authorization Code request.
  • Adding OIDC scope to the Fetch Access Token call. This call then returns an ID token (JWT format) along with an access token.

The ID token is the main addition to the existing OAuth flow. The client can then use this ID token to fetch more details about the logged-in resource owner/user. You will notice that there are no changes in the resource configuration. The only requirement is to republish the resource/API once the OAuth provider configuration changes are done.

To understand the OIDC functionality and the ways in which it can be used in APIC to further complement the API’s security, you will be building upon the work done in the Applying OAuth 2.0 section of this chapter. You will modify the existing OAuth provider and will make modifications to the testing flow that was covered in the Testing OAuth flow section.

OAuth provider changes

There are a few provider changes required to accommodate OIDC. Let’s walk through those changes:

1. Log in to API Manager. Go to Home | Manage resources | OAuth providers section. Click on the api-security-native-oauth-provider OAuth provider.
2. Click on OpenID Connect. Select Enable OIDC. Clear all the selections under Support hybrid response types. Select Auto Generate OIDC API Assembly. Refer to Figure 7.23:

Figure 7.23 – Enable OpenID Connect in an OAuth provider

3. In the OpenID Connect view, you will either need to provide an ID token signing crypto object or an ID token signing key (a JSON Web Key or JWK) to sign the ID token generated by APIC. The reason to sign the ID token is so that the receiver of this token (the client) can be sure of the validity of the token generator. For the purposes of this tutorial, you will generate a JWK using https://mkjwk.org/. Refer to Figure 7.24:

Figure 7.24 – JWK generation

JSON Web Key (JWK)

JWK is a JSON object representing the cryptographic key used for signing. You can generate a JWK using publicly available open source libraries (for example, https://openid.net/developers/jwt/), public websites (for example, https://mkjwk.org/), or the libraries/methods approved by your company’s security department. The use of an online tool such as https://mkjwk.org/ is for demonstration purposes only. It is not a recommendation. Please consult your organization’s security administrator for the approved method of JWK generation and usage.

4. Copy the generated JWK to the ID token signing key field. You can consider using a text editor to convert the generated JWK into a single line so that it can be copied easily to this field.

5. Select HS256 in the ID token signing algorithm field. Refer to the following screenshot. Click Save.

Figure 7.25 – ID token signing

JWK versus Crypto Object

ID token can be signed using two mechanisms: Using a JWK (like you just configured), or by using crypto objects available in the DataPower appliance (in which case you will need to supply the crypto object’s name in the ID token signing crypto object field). Crypto objects take precedence over JWK, in case both are specified. These crypto objects must be in the APIC domain on the DataPower appliance. Crypto objects can either use a shared secret key or a crypto key (private key) to encrypt or sign the ID token. Refer to the IBM documentation for algorithm support for a shared secret key and crypto key: https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=policies-generate-jwt.

From the OAuth provider configuration perspective, these are the only required changes to enable OIDC security. Make sure that you do the following:

• Republish your patient-information API to ensure that you are testing against the latest API version. Refer to Figure 7.26:

Figure 7.26 – Republishing the API changes

• Recreate the subscription for your corg-app application. Refer to Figure 7.19.

Next, you will cover the testing of OIDC security.