Retrieving and Revoking Tokens by External User ID

[anonymous]

There are a few use cases I have that involve bulk retrieval/removal of tokens in my application. Specifically,

• When a user removes their account, all tokens for the user should be revoked.

• When a user no longer wants a connection with a specific app, all tokens for the user and application should be revoked

• A user should be able to, at any time, view the applications that currently are connected

From my applications perspective, I want to be able to provide a user id from the application in order to get all tokens or revoke all tokens.

Apigee (kinda seems to) support this, as referenced in Get OAuth 2.0 Access Token by End User ID or App ID.

A quick note about my application. I’m using Apigee to expose an API for an existing application. The application is complete and mature. All user management is done in the application, and all data is stored their as well. Apigee, for my application, is really just a pure-proxy with some extra goodies like Application and OAuth management thrown in.

However, the functionality only seems to be enabled via the management API. So here’s my question, if I want to do this, what’s best practice for doing this?

1. Wrap the management API into a proxy that I expose only to my application. The Best Practices for API Proxy Design and Development actually says don’t do this.

   “Do not call the Edge management API from inside API proxies. The management API is used for administrative management purposes, not API flow logic. Policies are provided for interaction with API.”

   Is this an example where the best-practice can be broken? On the surface, this seems like my ideal solution.

2. Call the management API from my application directly.

   Potential downsides of this. My application is already hitting a few proxies as an EDGE application. I’d have to introduce a secondary authentication mechanism (HTTP Basic) for accessing the Management API, and when the Management API data structures aren’t ideal, I’ll need to have my application handle the details. Basically, some of the benefits of using EDGE as an API Proxy get lost.

3. Skip the management API all together. Upon OAuth token grants, call out to our Application (or BAAS) and store the OAuth token details. I’d also need to do this on OAuth token revokes to keep things synced up. Then have the application retrieve these details directly when needed.

   This just feels like more complexity than is really needed, but is technical feasibility.

And my side-question. Why isn’t this just part of the Apigee OAuth2 policies? Am I missing something?

[anilsr]

Dear @Tom Schaible ,

Welcome to Apigee Community. Great use cases & Great Question!

Yes, the functionality is enabled via the management API. I have seen similar use cases & the way we solved is using Apigee Developer Portal.

If Use Case is Revoking Keys Related to Developer Apps:

Why, Apigee Developer Portal? Please find reasons below.

• It’s already secured & connects to Apigee Edge via Management API.
• Apigee Management API PHP SDK helps you quickly build the application inside Apigee Developer Portal (built on open source Drupal CMS). Apigee Developer Portal talks to Apigee Edge using Apigee Management API PHP SDK. It’s available out of the box in Apigee Developer Portal.
• Easy to build screens & workflows using drupal custom modules.
• Out of the box support for Roles & Permissions using which you can restrict access to screens.

You need drupal expertise to build these screens where you can manage keys / apps. It’s possible and we have implemented similar requirements in past.

If Use Case is Revoking Access Tokens generated for End Users:

• Create a new proxy altogether called “apigeeManagementApi” & secure Apigee Management API using OAuth2.0 policies.
• Your target endpoint will be apigeeManagementApi endpoint. Store base64 encoded credentials in keyvaluemaps & use same in above proxy to make a call. You will first validate using OAuth2.0 before you hit Apigee Management Api.
• Create an Api Product & Developer App to generate access tokens & use these access tokens in your Application to make Management Api call from your application.

“Do not call the Edge management API from inside API proxies. The management API is used for administrative management purposes, not API flow logic. Policies are provided for interaction with API.”

I think above statement applies if you are making a service callout or API call inside a proxy to management API. I believe it’s perfectly fine to create a dedicated proxy for management API , secure it using OAuth2.0, access to only access token realted Apis and use same in your application by using access tokens mechanism instead of Basic Auth.

[anonymous]

Thanks for the detailed answer!

I’m a bit confused as to why the Apigee Developer Portal would be helpful in this situation, though.

I’ll use Strava (an exercise tracker) and My Fitness Pal (a food diary) as an example to illustrate why.

In this example, a user has a Strava account, and uses that primarily to track cycling activity. The user then starts to use My Fitness Pal, and would like to have their ‘Extra Calories’ imported into My Fitness Pal from Strava.

Great! Strava Developers have created an API, and the My Fitness Pal developers have built an integration against it to do just that.

I’d expect Strava to be the owner of the Developer Portal, and the My Fitness Pal developers, would actually be users of the portal.

So the user does an OAuth2 authorization, which lets My Fitness Pal retrieve the users data from Strava.

The user can also log into Strava at anytime, however, and Strava has a section of Settings called ‘Social Connections’ which lists all the connected apps. In this example, the user will see My Fitness Pal listed under this section.

The user shouldn’t be exposed to the Developer Portal in this case. They expect this info to be in Strava directly.

Rather, the Strava developers should have developed this info directly into Strava, and presumably did so via an internal API or other connection to their OAuth 2.0 server.

This is what I’m trying to replicate in my app. The Management API resources seem like the perfect way to do this, but their placement in the Management API and not the OAuth2 policies has thrown me for a loop a bit.

[anilsr]

@Tom Schaible ,

Thank you for more details.

My Bad, Earlier, I was thinking about Apigee Developer Apps & Revoking access to Developer Apps. I just realised it’s not about Developers & Keys, It’s more about Application End Users & OAuth Credentials & Access Tokens. Correct me if i am wrong.

For your use case, I would suggest

• Create a new proxy altogether called “apigeeManagementApi” & secure Apigee Management API using OAuth2.0 policies.
• Your target endpoint will be apigeeManagementApi endpoint. Store base64 encoded credentials in keyvaluemaps & use same in above proxy to make a call. You will first validate using OAuth2.0 before you hit Apigee Management Api.
• Create an Api Product & Developer App to generate access tokens & use these access tokens in your Application to make Management Api call from your application.

“Do not call the Edge management API from inside API proxies. The management API is used for administrative management purposes, not API flow logic. Policies are provided for interaction with API.”

I think above statement applies if you are making a service callout or API call inside a proxy to management API. I believe it’s perfectly fine to create a dedicated proxy for management API , secure it using OAuth2.0, access to only access token realted Apis and use same in your application by using access tokens mechanism instead of Basic Auth.

[anonymous]

Hi @Tom Schaible as @Anil Sagar mentions it’s perfectly fine to create a dedicated proxy that calls management APIs but to ensure that its not in the run-time path & is used solely for administrative purposes which seems to be the intent in your case.

Looks like in your case building out an proxy & exposing it to your app seems like the simplest solution.