Get in touch: info@samuelfair.com

Applying OAuth 2.0 – Digital Transformation with IBM API Connect

In this section, you will learn about the specifics of OAuth, and later you will learn about OIDC (another similar security standard). Because of similarities between OAuth and OIDC, it might be helpful to know at a high level what is what. It is important to know that while OIDC deals with authentication, OAuth deals with authorization. OIDC gives you a single login for multiple sites. OAuth provides you with the ability to control access to your data on a single site, by multiple sites.

So, what is exactly OAuth?

OAuth 2.0 is a security standard that allows one service (for example, a healthcare provider) to securely access limited data (for example, some lab results) from another service provider (for example, a medical lab) without ever having access to the person’s account credentials (username and password) shared with the other (medical lab provider). OAuth solves the authorization problem. Because of OAuth, a patient can now delegate limited account access (lab details) to their healthcare provider.

In the context of APIC, the implementation of OAuth security involves the following main steps:

  1. Create an OAuth provider.
  2. Make the OAuth provider available to a catalog.
  3. Enable OAuth security in an API.
  4. Create a test client that will invoke the API.
  5. Test the OAuth from the resource owner’s perspective.

In the Configuring native OAuth providers section, you already took care of the first two steps. We will now build upon the work you have done thus far and complete the remaining steps.

Enabling API with an OAuth security definition

OAuth is one of the security definitions types available to secure an API. You will now secure your patient-information API using the OAuth provider api-security-native-oauth-provider:

  1. In API Manager, open the patient-information API proxy. Navigate to its Design tab | Security Schemes. You can keep the existing security schemes.
  2. Click the Add + button in the Security Schemes section.
  3. Create an OAuth oauth-secdef security definition as per Table 7.4. Leave the default values for the Authorization URL, Token URL, and Scope fields.

Table 7.4 – OAuth security definition

Your completed security definition should resemble Figure 7.15:

Figure 7.15 – OAuth Security Definition

You will use Authorization URL and Token URL to test the OAuth flow in the Testing of OAuth flow section. Notice that the Scopes field of the OAuth provider is pre-populated. In the case of multiple scopes, keep the scope that is relevant for the API on which the security definition is applied. In this example, your OAuth provider only manages the patient-detail scope. Therefore, you do not need to make any changes to Scopes.

4. Click on the Save button to save the oauth-secdef security definition.

5. Apply the oauth-secdef security definitions to the security of your API. Go to the Security section. You will find clientID, oauth-secdef, and http-auth-url security schemes listed under the Security view. You should now be able to select oauth-secdef as the security scheme and the patient-details scope. Unselect the http-auth-url definition. Refer to Figure 7.16:

Figure 7.16 – Client ID and OAuth Security

Save your API.

6. Since you removed the http-auth-url security from your API, you must republish your changes. Use the toggle facility (refer to Figure 7.12) to republish your changes.

From the resource’s (API) perspective, what you have done so far applies the OAuth security to your REST proxy. These steps of creating the OAuth provider, assigning the provider to the catalog, and attaching the OAuth security definition to the API make the API OAuth safe. The API provider’s role generally finishes after these steps.

There is much that happens from the client’s (API’s consumer) perspective, though. You should get an understanding of the client’s configuration as well. OAuth providers grant type configuration, which you did earlier (refer to Figure 7.7), and this directly impacts the client’s interaction with the API. Next, you will see the client-side configuration and the steps to register the client with the API.

Leave a Reply

Your email address will not be published. Required fields are marked *