Like other OAuth configuration steps, testing the OAuth flow is also a multi-step process. This is due to the nature of multiple interactions between all the parties involved in OAuth processing. Apart from the complexity of the multiple parties, OAuth flow also changes based on the configured grant type in the OAuth provider.

You will be performing testing for the access code, sometimes referred to as the three-legged flow. You will remember that in the case of the access code or three-legged flow, the client does not have any access to the resource owner’s credentials. The resource owner is directly authenticated by the authorization server before the control is returned to the client along with the authorization code. The client then makes a separate call to the authorization server to request the access token and to access the resource on the resource owner’s behalf. Let’s see how we can begin with testing.

Prerequisites for OAuth testing

The following are these steps that are required to be performed for conducting a successful test of the OAuth flow:

1. In the absence of a testable client/application, you will be simulating the client functionality using a combination of a web browser and a REST API testing tool (for example, Curl) to test the OAuth flows. Make sure you have access to any standard web browser and a testing tool such as Curl.
2. You will also need access to the gateway service URL of your catalog to invoke the authorization path, token path, and API path. To get to the Gateway service URL of your catalog, navigate to the Home screen | Manage catalogs tile | Sandbox tile | Catalog settings tab | Gateway services section. Refer to Figure 7.21:

Figure 7.21 – Gateway services URL

The required URLs for testing the OAuth flow should look like the URLs provided in Table 7.7:

Table 7.7 – OAuth testing URLs

Replace $(catalog.url) with the captured Gateway URL value (refer to Figure 7.22).

3. You will need the client ID and client secret values that you copied earlier.

4. You will need the scope value of the patient-information API/resource. The scope value is patient-detail.

5. Lastly, you will need valid Basic Auth user credentials: user and pass.

Now that you have gathered all the required prerequisites, it is time for you to test your OAuth flow.

Access Code or three-legged flow

This flow is known by multiple names: access code, authorization code, or a three-legged flow. As was discussed earlier, this flow involves all the participants, that is, the resource owner, client (application), and resource server/authorization server. The basic steps to test this flow are as follows:

1. First, we fetch the authorization code. The client initiates access to a protected resource on behalf of the resource owner. It uses the authorization path for fetching the authorization code. A sample authorization path will look like this: https://$(catalog.url)/api-security-native-oauth-provider/oauth2/authorize?&client_id=dfb4e366ef3ccceefc9cfa914e14a540&response_type=code&scope=patient-detail.
2. Replace the $(catalog.url) and client_id values as per your environment. Notice scope=patient-detail. There could be multiple scopes (each scope could be attached to numerous APIs) that the same client could access from the resource server. Therefore, the client needs to let the resource server know about the scope to which the current access is requested.
3. After replacing the values of $(catalog.url) and client_id, copy the authorization path in your browser window and press Enter. The resource server’s OAuth security kicks into action. It utilizes the facilities of an authorization server to initiate a resource owner authentication process. Your browser should challenge you with an authentication prompt. Fill in the fields in the authentication prompt as Username=user and Password=pass. Refer to Figure 7.23:

Figure 7.22 – Authorization path and authentication challenge

4. Press Enter. Once successfully authenticated, your browser URL should change to the redirect URL you supplied while configuring the client. The authorization server will present an authorization code. Notice the code query parameter along with the long authorization code value that you have received from the authorization server. The address in your browser should look similar to https://example.com/redirect?code=AAIHooRpu0WL3Zf6EhueWlKEuhT5p8G7I81UhmfoymKwS2BcVEfzlMH-O966EvS-1FKY8NVeeLd9uXcwPVGG93r3CGolnXqCkuP8HdulBD0fqQ.

5. Copy the value of the code query parameter. You will be using this value to fetch the access token in the next step.

6. Then, fetch the access token. After successfully getting the authorization code, the next step in the OAuth flow is to fetch the access token. The access token is a validation of the client by the authorization server. You will use the Curl tool to test this part of the flow. The sample curl command should look like the following:

curl -v -k

-X POST “$(catalog.url)/api-security-native-oauth-

 provider/oauth2/token”

-u $(client_id):$(client_secret)

-d “grant_type=authorization_code&code=$(Authorization

 Code)”

-H “Content-Type: application/x-www-form-urlencoded”

Build your Curl command along similar lines (sample command):

curl -v -k

-X POST “$(catalog.url)/api-security-native-oauth-

 provider/oauth2/token”

-u dfb4e366ef3ccceefc9cfa914e14a540:3ce9e2601e7b296115

 d6b60207f707af

-d “grant_type=authorization_code&code=AALU6PpJBTnG

 GC2w7pcY14fiM1A3JewkBHT0a7HzDY5aVtUvzJIMvpFOq8V

 CX41eARGSmy7sw6kykqvn-DKIJVrUz1Uli3pkGNl9E9T78GUm4A”

-H “Content-Type: application/x-www-form-urlencoded”

7. Replace $(catalog.url), $(client_id), and $(client_secret) as per your environment. $(Authorization Code) should be replaced by the authorization code value you fetched in the Fetch Authorization Code step.

8. Next, send your curl request. The Curl command should return an access token in the access_token field. The sample response should resemble the following:

{

“token_type”: “Bearer”,

“access_token”: “AAIgZGZiNGUzNjZlZjNjY2NlZWZjOW

NmYTkxNGUxNGE1NDC757l_QNkH9DGjU23GqRx58N

96SeRDccX9RwbLmt5y5locz0Y-ww4K_DFGEqFqELa_

nfELawWuJiTmRQ_L8ouqjTQ_bghbz1QClkrlhEtIZg”,

“scope”: “patient-detail”,

“expires_in”: 3600,

“consented_on”: 1623919415

}

The returned access_token value can be used by the client to access the resource. This access_token is only valid until the duration specified in the expires_in response parameter. The default expiry is set to 3600 seconds that is, 60 minutes. The client can make multiple resource calls within this duration using the same access_token. This default value of 3600 seconds can be changed while configuring the OAuth provider.

9. Then, make a resource/API call. This is the last step in your testing process. You (acting as the client) will now make the resource/API call using the access token (access_token) that was retrieved in the previous step. In the Curl tool, create a new request as per the following Curl request example:

Curl command

curl -v -k

-X GET “$(catalog.url)/patient-information/patient”

-H “Authorization: Bearer $(Access Token)”

-H “Accept: application/fhir+json”

-H “X-IBM-Client-Id: $(client_id)”

Sample command

curl -v -k

-X GET “$(catalog.url)/patient-information/patient”

-H “Authorization: Bearer AAIgZGZiNGUzNjZlZjNjY2NlZW

 ZjOWNmYTkxNGUxNGE1NDD_QpPhIKzfdr-vZ79lqShm

 4ZGWLXKP2dJBc9YV3OgJguP6d_vz9mZ_nJ_Iy_MdQ

 rDQIr_Q6XJWxD0PuU6_jFz3XtAjgoDc6VFo5KCPuJmnfg”

-H “Accept: application/fhir+json”

-H “X-IBM-Client-Id: dfb4e366ef3ccceefc9cfa914e14a540”

Replace $(client_id) as per your environment. $(Access Token) should be replaced by the Access Token value you fetched in the Fetch Access Token step.

10. Finally, send the curl request. You should receive a valid response back from your patient-information API.

This concludes the testing of the access code or three-legged OAuth flow.

In this section, you learned how OAuth can be used to secure the APIs. At its core, OAuth is an authorization mechanism. It still leverages an external authentication framework for carrying out user authentication without any means to fetch meta-information about the user itself. This is where OIDC comes into the picture. It is a layer that sits on top of OAuth and enhances the OAuth flow by closing some of these user information-related gaps. You will now look in detail at how APIC supports the OIDC standard.