Just what is an OAuth provider? An OAuth provider is a service provider that provides authorization services via an Authorization Server to the Resource Owner (typically the end user) and to the Client (typically the applications trying to access the Resources on the resource owner’s behalf). An OAuth provider is a third party that is trusted by the resource owner and the client alike. To facilitate this OAuth-based communication, the provider provides an authorization code and access token.
You will use API Manager to create a native OAuth provider. After completing the provider configuration, you will enable this provider in the Sandbox catalog. A native OAuth provider allows the use of native capabilities of APIC to perform OAuth authorization tasks. Of course, APIC allows you to utilize third-party OAuth providers such as Amazon Cognito, Google OAuth 2, Okta, and Facebook Log. The integration with such third-party providers will not be covered here. You will instead create a native OAuth provider by utilizing APIC’s OOTB capabilities. Follow these steps:
- Log in to API Manager. Go to Home | Manage resources | OAuth providers. Click on the Add button and select Native OAuth provider.
- On the Create native OAuth provider page and provide the following values. You can leave the rest of the fields as their defaults.
Title: api-security-native-oauth-provider
Gateway Type: DataPower API Gateway
3. Click Next. On the Configuration page, keep the default values for Authorization path and Token path.
Under Supported grant types, choose Access Code and Resource owner – password.
Under Supported client types, keep the Confidential checkbox selected. Refer to section 1 of Figure 7.7:
Figure 7.7 – OAuth provider configuration
Here are some important details about the various fields in section 1 of Figure 7.7:
- Authorize path is the standard OAuth endpoint for authorization. It is a path on the authorization server invoked by the client to retrieve the initial authorization code.
- Token path is also a standard OAuth endpoint. It is a path on the authorization server invoked by the client to retrieve the final access token in exchange for the authorization code. The access token is then used by the application to call the protected resource/API.
- Access code (also known as an authorization code grant type) is a preferred choice when there is a low degree of trust between the resource owner and the client. The resource owner performs an independent login with the authorization server and receives an authorization code. The client then exchanges that authorization code for an access token from the authorization server.
- When you choose the Resource owner – Password grant type, you are specifying that the client has access to the resource owner’s credentials (username and password) and that there is no need for an extra fetch authorization code step. It is typically used in scenarios where there is a high degree of trust between the resource owner and the client.
- You do not have to choose both grant types. You can choose either of the grant types to adjust how OAuth is executed. For your OAuth testing in this section, you must keep the Access code option selected. For more details on the other grant types, visit https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=authentication-configuring-native-oauth-provider.
Note
You can apply the following rules of thumb when selecting one of the preceding grant types:
Access code: Use when the resource owner does not want to share the user credentials with the client.
Resource owner – Password: Use when the resource owner is willing to share the user credentials with the client.
4. Click Next. On the Scopes page (section 2 of Figure 7.7), overwrite the default scope, sample_scope_1, with patient-detail. Do the same for Description. A scope is an access control mechanism enforced by the authorization server on the client. It provides the authorization server with a way to notify the resource owner about the resources that are accessed by the client on the resource owner’s behalf. After updating the default scope, click Next.
5. On the Authorization endpoint page, keep the values as shown in section 3 of Figure 7.7. Although you are selecting the default values, the Identity extraction and Authorization values can also be an HTTP (default or custom) HTML form. This form provides for the ability to customize the resource owner’s interaction (generally, the login form and the scope permissions pages) with the OAuth process. This form is not available in the case of a third-party OAuth provider as in that case, the interaction between the resource owner and the authorization server is controlled by that third-party provider itself. Click Next.
6. You will be presented with a native OAuth provider summary. Review the summary information. You will notice that the Base path value is empty. APIC will automatically generate this value for you after you click on the Finish button. The Base path value will be used to construct the complete URLs for the Authorization URL and the Token URL. You will see this later in Figure 7.15 when you apply the OAuth security definition to your API. Click Finish.
With the OAuth provider now created, the next step in the process is to make the OAuth provider available to the catalog where the OAuth protected resource(s) will be deployed. Here is how it is done:
- Click the Manage icon on the left navigation of API Manager and select the Sandbox catalog.
- Click the Catalog Settings tab | OAuth providers. Click on the Edit button to add your newly created OAuth provider. Your newly created OAuth provider, api-security-native-oauth-provider, will be displayed on the screen. Select the checkbox and click Save. Refer to the following screenshot:
Figure 7.8 – Adding the OAuth provider to the Sandbox catalog
With the preceding configuration, you are now ready to use the OAuth provider to protect the API resources using OAuth2 security.
This concludes the section on User Registry and OAuth provider preparation. The following sections of this chapter will guide you through the process of applying the security to your APIs, using the various resources you just created. You will begin by protecting an API using Basic authentication with the Authentication URL method.
Leave a Reply