Grant Revocation at Acct level not full scope


#1

What is the standard implementation for revoking access at the acct level rather than the scope level? I see often is that authorization is for scope and may include sharing access to several layers of data for a few accts. if customer wants to revoke for only one of those accts within the scope / grant originally authorized, it seems pattern is to do a re-consent and de-select one or more of the accounts on the consent experience. Problem is that generates a new access token which may now require requestor to send multiple requests for one customer. does Oauth spec allow for acct level vs. scope (scope has 2+accts in it) revocation? Thanks.


#2

The way that I like to look at OAuth 2.0 Bearer Token is it is for the Issuer-Audience-User level. To put it another way, if you imagine an access token with no scopes, and you have a resource server that wants to just do plain old validation of the access token, is it validating the issuer and audience.

Revoking the token is a blunt object to deny access.

Scope revocation is useful for removing particular access or limiting the amount of information that comes from one API.

There is the audience level, which can be model out multiple authorization servers in Okta, but this might not work correctly with your data model and your appetite to handle multiple access tokens for a single application.

The reality here is when you need to change authorization, you need to get new tokens, so regardless how you model it out, you will need to work with the authorization server to get new tokens.

Make sense?


#3

It does, but are you saying that if end user consents again to same api but less info, a new access token is created. Is the old access token which may not have expired still valid? Meaning the client can call with either token but would only get data from the most recent consent?

Thanks!


#4

Ah, I see what you are saying now. I had to read between the lines earlier and now this is clear.

What you would want to do is either:

  • Orchestrate the revocation and consent through your own API, this will make sure that they don’t have access to access tokens that shouldn’t be used
  • Use refresh tokens and short TTLs for the access tokens so they will ultimately expire fast

I’m partial to the 2nd approach because it is easier to implement. You could set a 2-minute timeout for access tokens and a refresh token for N days to support this.

OAuth 2.0 doesn’t have good specifications on how revocation and consent should operate. Consent doesn’t really have a spec.

Let me know any questions,
Tom