Create a page for end users to manage OAuth authorized applications

[devin15]

I'd like to create a page inside my application to enable end-users to manage the OAuth applications that have access to their account. This is a standard feature for all OAuth providers. How can this be implemented with Apigee?

This is what I've figured out, but it seems overly complex.

1. Fetch all access tokens for a user by iterating over `oauth2/search` while filtering with `enduser` (there's no filter for active only)
2. Fetch each token to get the `appId`
3. Find the unique set of app IDs across all tokens

There are several problems with this:

• No way to tell if an application's access has already been revoked (access tokens are revoked, but are refresh tokens revoked too?)
• The set of access tokens can be large, so it needs to be done as a background job

[dchiesa1]

I understand what you're saying..... and.... I think managing TOKENS is different than managing APPLICATIONS.  

Your idea is to collect tokens. But that's probably not useful.  As a user I don't want to worry about tokens.  As a user I want to know if App X has access to my photos, or prescriptions, or running history, or etc.  Managing the apps, not the individual tokens.

In a 3-legged OAuth flow, the login-and-consent experience is responsible for 

• authenticating the user
• gathering consent of the user.  "Do you want to allow application X access to A, B, and C"? 
• if successful, generate an auth code and redirect the browser to the /token endpoint.

The login-and-consent is usually implemented as a web application. It ideally should record the consent decision, in some persistent store, so that subsequent interactions don't ask the user the same question again. Let's suppose the user has consented for an app to have scope A.  Then the user gets a new laptop.  Installs the app again on this new system.  Let's not ask the user to grant consent again.  Therefore the consent experience must use a persistent store. 

If you've built THAT, then ... "managing apps" is a small extension to the login-and-consent experience. Basically,

• authenticate the user
• read the database for consent records, filtered by the authenticated user.
• allow the user to "untick" a box associated with each app
• On submit, remove all those consents from the datastore

Any existing tokens will be valid until they expire.  There is no need, really, to expire tokens, if your token lifetime is brief enough.

Then, you should enhance the login-and-consent flow so that it does this:

• authenticate the user
• read the database for consent records, filtered by the authenticated user, and by the current app asking for consent
• if there is an existing record, the user has already granted consent. If not, ask the user for consent.
• If consent has been granted, insure that decision is recorded, then generate an auth code and redirect to the /token endpoint

If you make your token lifetime small enough you don't need to worry about revoking all the tokens for an app that the user has de-listed. Those tokens will expire in 10 minutes.

You can separately build a "sign out" experience that invalidates the current token, if you like. This would be independent of the granting or revoking consent for the app. Two distinct levels of authorization.

Apigee currently handles token generation and lifetime management. Apigee does not provide assistance for managing consent. Various customers have built their own tooling for this.  We are looking into building more capability in this area.