OKTA integration with API Gateway

[Rick Reed]

Our company is currently switching their authentication pattern to the new OKTA pattern.

I am wondering how to integrate the OKTA authentication into our API Gateways (v9.4 and V10).  We are currently using OAuth2 and BasicAuth to validate users and internal service to service calls.

Any documentation to start with on best practices for this type / level of integration?

Thanks.

[Barry Stern]

Hello Rick,

Are you looking to have the gateway use okta as a identity provider and support SSO with OKTA or are you looking to Integrate the OTK with OKTA?

Attached is a sample policy that shows how you can use OKTA for authorization code flow if you are not leveraging the OTK. 
To use this policy first you will need a client application registered with OKTA with the proper redirect defined back to the gateway.
When a user calls the service it will redirect the client to OKTA authorization server for authentication
Oka will redirect the client back to the gateway service with the code 
Gateway will exchange the code for tokens and returns tokens to the user.

Hope this helps get you started.
Barry Stern

Attachment(s)

okta_OIDC.xml   16 KB 1 version

[Rick Reed]

Barry,

Thanks so much for the information and the policy example.  

To be honest, I am still trying to determine the exact flow that will be required by this OKTA pattern.  We do have the OTK installed on our gateways and we are using it as 1 of our authentication patterns. 

From your flow example, this appears to be using some type of OAuth integration in order to exchange the OKTA auth code for an OAuth2 token unless I am just not fully understanding at this point.  This is how I am seeing the flow, please confirm.

• Client registered with OKTA which gives us the client_id / client_secret (like our own OTK does today)
• Client / Service / etc calls our gateway endpoint passing HTTP headers for code / action / provider
  • if action is empty, we return an HTTPCode 302 setting an auth_req_url (for redirect?)
  • this redirects to the OKTA /v1/authorize endpoint for gateway client authentication which sends back an authorization code once completed to this same policy, which then redirects back to OKTA /v1/token endpoint to exchange the AuthCode for an OAuth2 Token.

So this is just doing a High Level "Is our API Gateway as an OKTA client, valid" or does the OKTA authorize take that a step further and ask for individual username / passwords in order to authorize the user as an individual before issuing the Authorization Code?  

I assume you have another policy that handles the Authentication of an OAuth2 token that has been passed via the HTTP Authorization: Bearer <token> header that would verify with OKTA that the token is valid?

Can we set this up to use our existing OTK for the OAuth2 token processing once OKTA has validated the user?

sorry for all the question, just trying to get a better understanding of these complex processing flows.

Thanks.

[Barry Stern]

Rick,

The actual implementation on the gateway for integration with OKTA will vary based on your desired behavior. The sample I provided is just one of many possibly variations for integrating OKTA. This is assuming the gateway is strictly acting as a resource server and on OTKA is the authorization Server and token Server.

In this sample I supplied when the user is redirected to okta authorization server, OTKA will present the login form for supplying user credentials and verify the user credentials before redirecting the user back to the gateway with the code.

if you want to accept OKTA Oauth tokens for accessing APIs on the gateway as a  Resource Server then you would add  token validation in the APIs on the gateway.  This can be a passive validation where the gateway policy can examine the JWT  access_token for validation of the claims.  Or the gateway can  call the OKTA introspection API to validate the token 

${baseUrl}/v1/introspect

[Rick Reed]

I think I follow.

 

So in essence, we could retire our internal OTK Database if we use OKTA as both our Authorization/Token server using the API interfaces available via OKTA?

 

Rick Reed | API Architect | FXF Architecture & Delivery | FedEx Services | Colorado Springs
Tel: [phone] | Mobile: [phone]

 

[Barry Stern]

That is one possible option.

However there is ability to have OKTA just be the Authorization/login (similar to social login with the MAG) server and then have the gateway OTK still being the token server and the resource server.