OIDC security testing follows along the same path as OAuth flow testing, with some minor changes. From the resource owner’s standpoint, the overall interaction flow looks identical to OAuth. The notable differences rest in the following:

1. Fetch Authorization Code: Instead of a single scope value, the client sends two scope values to the authorization server; for example, in the case of OAuth flow, the scope=patient-detail value is used. In the case of OIDC flow, the same authorization code call is made with scope=patient-detail+openid. Notice the plus (+) symbol used between the two scope values. A sample authorization path URL will look like this: https://$(catalog.url)/api-security-native-oauth-provider/oauth2/authorize?&client_id=dfb4e366ef3ccceefc9cfa914e14a540&response_type=code&scope=patient-detail+openid.

OpenID scopes

Notice the two scope values sent as part of the OIDC call. The primary scope value is patient-detail. The other scope value is openid. The scope value of openid is part of OIDC’s list of built-in scopes. These scope identifiers, as they are called, have different purposes. Some of these are briefly explained here:

openid (required): This indicates that the client intends to use OIDC to verify the user’s identity.

profile: The client wants to request access to name, family_name, given_name, middle_name, picture, and such.

phone: The client wants to request access to phone_number and other phone number-related information.

Replace the $(catalog.url) and client_id values as per your environment. Copy the authorization path URL to your browser window and press Enter. After logging in, you will be redirected to a URL that contains the authorization code.

2. Fetch Access Token: There is only one difference between the access token call that you had earlier constructed while testing the OAuth flow and the access token call for OIDC. In the case of OIDC, the client sends two scope values as part of the Fetch Access Token call. Notice the space (%20) between the two scope values of openid and patient-detail. It is different from the Fetch Access/Authorization Code where the two scope values had a plus (+) between them:

Curl command

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)&scope=openid%20patient-details”

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

Sample command

curl -v -k

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

 provider/oauth2/token”

-u dfb4e366ef3ccceefc9cfa914e14a540:3ce9e2601e7b2961

 15d6b60207f707af

-d “grant_type=authorization_code&code=AAKwNX_f-

 GuOfdx17N78HYCkyj1p7YiW7A886zOK6uM3yMywG1ZWza37P

 pu7PYI7igKFejXxsgiYwYKnfpKmZuVdQbNy9eF-caNPS2L7vw

 Lh8w&scope=openid%20patient-detail”

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

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 earlier.

3. Send your Curl request. The Curl command should return an access token. The sample response should resemble the following:

{

 “token_type”: “Bearer”,

 “access_token”:

 “AAIgZGZiNGUzNjZlZjNjY2NlZWZjOWNmYTkx

 NGUxNGE1NDBxVgVhACO5Tl7OZg_yS1QbBZ5Wl8-

 31A_mudnPS3VuY8YP31jQ783oSyPXlFJZrdf3E5

 ucboDL9dl39AmEQ4oz7NHjulTWJBMJZ7vrCArhWA”,

 “scope”: “patient-detail openid”,

 “expires_in”: 3600,

 “consented_on”: 1624007362,

 “id_token”: “eyJraWQiOiJ5d1BYM0FlWE9JRDh3OHZVRzNBM

 2NvVVhOdkNMQzRSTjF3Ykw3ZGotSkd3IiwiYWxnIjoi

 SFMyNTYifQ.eyJqdGkiOiI5ODk2NTcwNS1mNmNmLTQ1NDct

 YTYxMS02NTU1NmMxOTg5Y2QiLCJpc3MiOiJJQk0gQVBJQ29

 ubmVjdCIsInN1YiI6InVzZXIiLCJhdWQiOiJkZmI0ZTM2Nm

 VmM2NjY2VlZmM5Y2ZhOTE0ZTE0YTU0MCIsImV4cCI6MTYy

 NDAxMDk2MywiaWF0IjoxNjI0MDA3MzYzLCJhdF9oYXNoIj

 oiLWJUVVFJSXBDMXF4QjNUZmY1V0ZWZyJ9.NnTcb92WQp2

 RNWMwjk6SNd75ODLwQWRdnxAFqhE0Cxk”

}

id_token is a JSON Web Token (JWT) format token value. access_token can be used by the client to access the resource (just like you did in the Access Code or three-legged flow section, in step 9, Make a resource/API call). id_token contains standard user information (email, name, and some other meta-information) from the identity provider and the signature of the authorization server (so that it can be independently verified by the client).

This section was an introduction to OIDC support in APIC. OAuth and OIDC together provide a formidable standards-based authentication and authorization framework. The last few sections demonstrated, with the help of theory and examples, that they both are comprehensively supported in APIC. You should leverage them to secure your APIs as much as possible.

The next section will introduce you, in detail, to the method of applying JWT-based security to APIs.