External Oauth2 Integration

[mattz]

We intend to use an external Oauth2 service providing a Token Introspection endpoint according to https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-06 / https://tools.ietf.org/html/rfc7662.

Is there any documentation describing how to integrate such a Token Introspection endpoint and omit the Apigee internal Outh2 altogether?

One big question we have here is, whether there really is a need to create an "Apigee token" for each external token as described here: https://community.apigee.com/articles/51127/integrating-the-curity-oauth-server-with-apigee-ed.html

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.

Seems pretty cumbersome.

[dchiesa1]

For question 1: I don't know of any documentation of the sort you describe. You could build the integration you're imagining. I don't know of any existing working examples, either. Probably you already understand how you would go about doing it (ServiceCallout, VerifyJWT).

For question 2, do you really NEED to create an Apigee Edge token, the answer is no.

The reason you might WANT an Apigee token is to allow Apigee Edge to collect analytics, and to perform the authorization check inherent in the API Product <=> API Key mapping.

Let me explain what I mean.

Suppose some external provider issues tokens. You can configure your Apigee Edge proxy to call out to the token introspection endpoint to verify the token. You can configure the proxy to also verify the signature on that token and then act on the claims. But at that point the Apigee Edge analytics system doesn't know anything about the inbound call. Your "proxy context" within Apigee Edge can be assured that the external token issuer has validated the token, but the Apigee Edge runtime doesn't know diddly.

To get something useful in the analytics records, you need to use one of VerifyApiKey or VerifyAccessToken in your API Proxy. Either is fine.

A solution that is possibly simpler than what is described in the answer you referenced is to synchronize the client_id's between your OAuth token issuer and Apigee Edge. Then when Apigee Edge calls out to the token introspection endpoint, and receives the signed JWT containing a client_id field, the proxy can then call VerifyApiKey using that client_id claim, to verify that the client_id is a valid API key within Apigee Edge and is valid for the currently executing proxy.

Doing it this way puts the onus on you to make sure the client_id's remain synchronized. If an admin removes or revokes a client_id from one side... what should happen to the other? This management is left to you.

[mattz]

Thanks for all those details! We intend to sync clients between the external Oauth2 service and Apigee Edge anyway, so that part is perfectly fine for us.

Given that, what you propose as solution using VerifyApiKey seems perfect fine to me. Its much simpler than creating copies of Apigee Tokens while having the same effect (if I understand you correctly).

We'll try to prototype this to see if we can get it working with the expected results (=working analytics).