#907 OIC & OAuth 2.0 Part 2

This is what I hope to implement over the next 2 posts. 

Here I restrict access to OIC endpoints, using OCI API Gateway. The flow is as follows - 

Client invokes API with OAuth token for the API.  API Gateway receives the token and then invokes a custom authorizer function. This function validates the token, then retrieves the OIC token. This is returned to API Gateway, which then replaces the original token in the request header. The request is then routed to OIC.

A big thank you to my colleague Valeria Chiran for her support here!

The previous post covered the OAuth setup at IDCS level. It ended with a test of the OIC endpoint from Postman, using the access token retrieved from IDCS. 

OIC customers value OCI API Gateway for many reasons, including the following -

1. Endpoint Virtualisation

2. Making it easy to expose a subset of integration endpoints to various clients - this could include 3rd parties.

3. Easy integration with 3rd party identity providers.

4. Ability to leverage a rich set of API Gateway policies - rate limiting etc.

For me, the focus will be on granting access to the following integrations -

AA-Salary-Test-MV supports multiple verbs - GET (get the salary based on empid) and PUT (update salary based on empid).

The rules are very simple - I have 2 sets of clients - users and admins. The users can read salary info, the admins can update salary info. 

Net, net - users should be able to invoke the OIC integration AA-SALARY-USERS as well as the GET on AA-SALARY-Test-MV. The admins should be able to invoke all endpoints. Let's begin by looking at the multiple verb integration - 

Let's agree to use 2 different scopes to enforce the rules - _userScope and _adminScope.

Many OIC customers require something similar, e.g. different trading partners requiring access to different sets of integrations. I have greatly simplified things here with my 3 integrations, but they will suffice to demonstrate the value-add of the combination API Gateway / IDCS.  

Deploy the multi verb integration to API Gateway

 

Check out the routing rules - 

Add a new routing rule /version

Try invoking /version from Postman -

Note no auth has been set.

Back to the API Gateway - let's secure the api by setting the authentication as follows - 

Note the use of IDCS as the Issuer.

Click Show Advanced Options -

Here I add my 2 scopes -

Validate in IDCS that clients can access the signing certificate - specified above in the Public Keys section.

Now we move to IDCS... 

Creating the required applications in IDCS

This is where the magic happens - 

Let's go thru these individually - 

AA-Salary-application - this takes care of the resources/scopes.

Note the definition of the 2 scopes _userScope, _adminScope.

AA-Salary-application-admins - this is specifically for admin clients.

Note the scope setting - anyAudience_adminScope

This is a concatenation of ALLOWED AUDIENCES and the relevant CLAIM VALUE.

Think back to the Authentication definition in API Gateway - 

A client Id and secret are generated. 

I do the same for the users - AA-Salary-application-users - same as the above except for - 

I also save the client id and secret generated - 

 

I test the /version endpoint again from Postman - 

As expected - Unauthorized.

Now I add the OAuth client details from the "users" app -

 

Token config is as follows - 

Access Token URL set to https://myIDCSURL/oauth2/v1/token

So now we have successfully tested limiting access to only authorised clients - OAuth 2.0 Authorization on OCI API Gateway, courtesy of IDCS.

I now publish the 2 remaining OIC endpoints to API Gateway -

Beginning with the admin only integration - AA-Salary-Admins -

Here I add the same Authentication rule - 

I add another route - /version - with the same stock response as in the previous example.

I test this with the client credentials from user - 

Now with the admin credentials - 

Summary

This post has shown how easy it is to protect API Gateway apis via OAuth 2.0. It detailed the resources required at IDCS level to make this work. Next step is to create the IDS app for OIC access as well as the custom authorizer function - work for the next post!