Okta is one of the popular Identity & Access Management solutions in the market. We have several customers that also happen to be Okta customers.
Here is a very common problem statement that we encounter with our customers:
In this short yet comprehensive demonstration, I cover topics like OAuth, Okta integration & Resource Owner or Password Grant flow.
In this flow all API traffic (Runtime API + Authentication / Token API) is proxied through Apigee Edge. Apigee delegates the end user authentication to Okta & generates an access token that can be used to access any API that is protected using OAuth policies. Apigee provides support for custom attributes that can be associated with an access token very easily. This is very helpful when you have to reference some values/ids returned by the Identity Provider and more importantly when you have to pass them along to the back-end APIs at run-time. Apigee Edge makes that super easy with OOTB policies.
Apigee also has support for external access tokens (i.e not generated within Apigee) that can be useful in scenarios when the tokens are coming from somewhere else (in this example from Okta). You will see 2 variations of the password grant: Access token minted / persisted within Apigee Access token minted in Okta (In this example I use the session id token returned from Okta as the access token) but persisted and recognized within Apigee as if it was generated within Apigee.
Some of the benefits of using this delegated model approach are:
OAuth Proxy bundles used in this demonstration:
Token minted in Apigee: oauth-ext-rev1-2016-07-23.zip
OAuth proxy bundles used in this demonstration are available on github.