OAuth Extension Grants - Delegation

Not applicable

Hello,

Is it possible to implement in Apigee something similar to OAuth Extension Grants as described in the Identity Server documentation?

http://docs.identityserver.io/en/release/topics/extension_grants.html

"OAuth 2.0 defines standard grant types for the token endpoint, such as password, authorization_code and refresh_token. Extension grants are a way to add support for non-standard token issuance scenarios like token translation, delegation, or custom credentials."

Example: Simple delegation using an extension grant

Imagine the following scenario - a front end client calls a middle tier API using a token acquired via an interactive flow (e.g. hybrid flow). This middle tier API (API 1) now wants to call a back end API (API 2) on behalf of the interactive user:

7176-delegation.png

In other words, the middle tier API (API 1) needs an access token containing the user’s identity, but with the scope of the back end API (API 2).

I tried to find something in the Forum but I couldn't find anything.

Thanks for your help.

0 1 1,268
1 REPLY 1

I don't quite understand how the "extension grant" idea works.

In Apigee Edge you can build and customize your OAuth2 token dispensary. You have control over how requests for tokens are handled.

  • if you like you can support only password grant
  • or client_credentials
  • or password and client_credentials
  • or you can support all of the "standard" grant types described in RFC 6749
  • or you can support a distinct grant type like "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" as described in RFC 7523, in which the token endpoint accepts an inbound JWT and returns an opaque oauth token

All of this is controlled by you.

Now, in your diagram, I guess Apigee Edge would be the thing implementing API 1, and some other backend system would implement API2.

You can configure Apigee Edge to send a request out to a different token endpoint, to obtain a token that would be valid for the backend system (API2). You can do that call out with the ServiceCallout policy, or with the JavaScript policy, or with nodejs logic running within a Hosted Target.

You said "API 1 needs an access token containing the user's identity"... But if the unnamed third-party token endpoint in that picture AUTHENTICATES the user then that's going to be problematic. Apigee Edge doesn't have the user credentials, and shouldn't.

It may be that the token sent from the client to API1 is a JWT and includes an authenticated identity for the end user. In that case Apigee Edge can call VerifyJWT to verify that identity and then generate a new JWT via GenerateJWT with the user's identity asserted within it. This second token might be passed back to API2.

Lots of flexibility; the approach you choose depends on what specifically you want to do.