LinkedIn
Twitter
When using Apigee to protect and proxy APIs, it can be helpful to use a purpose-built OAuth server like the Curity Identity Server. Doing so provides a number of advantages:
- Architectural separation of concerns, allowing the gateway to do what it does really well and the OAuth server to do what it does best.
- Extensive support for not only "vanilla" OAuth but also the related standards, like OpenID Connect with its hybrid flows, the device flow, introspection, revocation, token exchange, assisted token flow, etc.
When using Curity, in particular, there are also a number of additional benefits, like:
- Simplified management and setup
- Advanced authentication possibilities, including MFA, support for various login methods, user account linking, self-service signup, password resets, SSO, etc.
- User management using SCIM
With the help of this community, we have created a first-class integration of Curity and Apigee that delivers these benefits and others. You can find the entire article on the curity.io web site, complete with policies, shared flows, configuration, and testing instructions. For the benefit of this forum, we'd like to summarize and share it here.
The overall integration is shown in the following component diagram:
For more background on this kind of integration and the use of identities in the back-end microservices, refer to this Nordic APIs blog post.
Client Registration
Both Curity and Apigee have the notion of a "client" or an "app". What each needs this for though are quite different. In Curity's case, the client is the app that will request tokens; it is the computer program that the user will use to get themselves logged in. For Apigee, it is the thing that will make API calls to proxies that it exposes; clients are a fundamental metric by which Apigee reports on usage. Basically, Curity needs a client ID and secret for authenticating the client and issuing tokens to the user while Apigee only needed a matching client ID to properly report on API usage.
Registering clients in these two systems is done using Dynamic Client Registration (DCR). This will usually be done from the API portal, but this isn't a requirement because DCR is just a standard RESTful API. The full article has samples of the request/response and the API proxy that can be created in Apigee to register the client with Curity and then use the Apigee management APIs to also register the client app with the gateway.
The important parts of this integration to be aware of are that:
- The integration between the two products is standard based, ensuring that customers are not locked into either.
- The caller of this API can be anything, including homemade developer portals or processes. The API is very simple, requiring only a couple inputs encoded as JSON exchanged over HTTP (thus keeping the tech barrier very low and generic).
- App instances can be associated with specific users (using Curity's DCR functionality)
- Curity ends of with a client ID and secret (which it needs for issuing tokens using the various OAuth/OpenID Connect flows) whereas Apigee only maintains a client ID (for API reporting and usage)
This integration is shown in the following figure:
Token Issuance and Validation
Once the user has authenticated and a token has been issued to this effect, the app will make API calls which will be intercepted by Apigee. Apigee will validate these, extracting the associated app ID (i.e., the client ID) and report that that app has consumed a certain API. For this to work, Apigee must have some sort of "Apigee token" that its OAuthV2 policy can be used with. To this end, during token issuance, Curity registers an "Apigee token", associating that with the real token that the app is given. The steps to do so are shown in the following diagram:
As a result of this, the token that is later presented by the app can be interrogated to learn about the "Apigee token". Once it does, it can be validated and reported by Apigee. The full article explains how this works in detail. It also includes all of the steps to perform the validation in a shared API flow that can be reused across all protected APIs. The flow is summarized in this sequence diagram:
This is the gist of how the two products are integrated. Every step in every policy needed to realize this are available on our developer portal. The steps to verify the integration are also included.
Conclusion
We'd like to thank you for reading as well as @Sai Saran Vaidyanathan and the entire community for the warm welcome to this forum. We could not have come up with such a good integration and so quickly without the help and support we received here. We hope that this summary and the step-by-step guide will be useful in many API management integrations. If you have questions or reactions, please feel free to post them here or get in touch with us directly.
