How to Make Your Apigee Edge-Okta Integration Seamless
Okta is a popular identity and access management solution that shares several customers with Apigee. Often, customers whose API calls flow through Apigee and rely on Apigee as the OAuth provider for all of their apps also want to use Okta for end-user authentication. How can they make this a seamless process that adheres to standards as much as possible?
In this short yet comprehensive demonstration, we walk through integrating Apigee and Okta and discuss topics including OAuth and resource-owner or password-grant flows.
All API traffic (the runtime API and the authentication/token API) is proxied through Apigee Edge. Apigee delegates the end-user authentication to Okta and generates an access token that can be used to access any API that is protected using OAuth policies.
Apigee supports custom attributes that can be associated with an access token very easily. This is 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 runtime. Apigee Edge makes it simple with out-of-the-box policies.
Apigee also supports external access tokens (those not generated within Apigee—in this case, from Okta). You’ll see two variations of the password grant: access token minted and persisted within Apigee; and access token minted in Okta (In the demo we use the session ID token returned from Okta as the access token) but persisted and recognized within Apigee as if it was generated there.
There are several benefits to using this delegated model approach, including:
- It’s standards-based (OAuth 2.0)
- It enables security enforcement at the edge
- It enables responsive and secure APIs
- It provides end-to-end visibility into authentication traffic in addition to your run-time traffic
- It creates a seamless experience for app developers
We hope you found this useful. If you have any questions or want to discuss this, please visit community.apigee.com.