Token Revocation if user revoked consent

[AxelNennker]

During our Feb 28. meeting @izahirclemencia put the link to RFC7009 into the chat and remarked that implementers have to revoke tokens if the user revokes consent.

During the meeting we agreed that consent must be re-evaluated if a refresh token is used to request a new access token.

These are related but different topics.

I suggest adding text to our profile that says that if the user revokes consent at the client then RFC7009 MUST be used to revoke tokens and that Camara AZ MUST provide a token revocation endpoint according to RFC7009.

This "MUST" is certainly open for discussion, and also which version this goes into.

RFC7009 does not talk about consent revocation at the operator or aggregator. There implementers are free to use whatever means they see fit to revoke tokens. Using RFC7009 between the user consent management system and the AZ is worth evaluating.

To the client side it is important to follow standards.

A note from RFC7009:

Note: A client compliant with [[RFC6749](https://datatracker.ietf.org/doc/html/rfc6749)] must be prepared to handle
   unexpected token invalidation at any time.  Independent of the
   revocation mechanism specified in this document, resource owners may
   revoke authorization grants, or the authorization server may
   invalidate tokens in order to mitigate security threats.  Thus,
   having different server policies with respect to cascading the
   revocation of tokens should not pose interoperability problems.

[izahirclemencia]

@AxelNennker RFC 7009 can be used to invalidate the tokens associated with revoked consent, eliminating the need for re-evaluation of refresh tokens through other mechanisms.

A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.

[garciasolero]

From our point of view, there is no problem in accepting the implementation of a token revocation endpoint based on RFC7009, as long as it is used for its intended purpose. That is, to invalidate a token no longer needed or leaked (and, if applicable, other tokens based on the same authorization grant).

RFC7009 does not deal with revoking consent. In other words, you can revoke a token, and the next time you request a token under the same conditions, you will still get it. Moreover, the authorization server must verify whether the token was issued to the client making the revocation request.

So if you want to define an API to allow a third party to manage consent, it should be a different one. But please note that task is already going to be done by the operators (the masters of consents).

[izahirclemencia]

@garciasolero could you specify under which condition you can request a token under the same conditions and still receive it?

From what I understand, the scenario @AxelNennker is trying to tackle is that if consent is revoked, the tokens should be re-evaluated on consumption. My take on this is to revoke the refresh token & access token so that after consent is revoked, both tokens cannot be used to perform actions on behalf of the subject, therefore fulfilling the need and eliminating the need to "re-evaluate" tokens.

[garciasolero]

@izahirclemencia,

You suggest using RFC7009 to revoke consent, but it is not designed for that purpose. RFC7009 is primarily intended to revoke tokens by the application for which they were created. Let me illustrate the scenario:

1. The app requests a token for specific scopes, obtaining an access token and a refresh token.
2. The app revokes the access token, and the related refresh token based on the same authorization grant.
3. The app makes another token request with the same scopes, then the app will obtain a new access token in the same manner.

Therefore, token revocation does not impact user consent or future token requests.

[izahirclemencia]

@garciasolero

I do not suggest using RFC7009 to revoke consent. Please reread my paragraph. Kind regards!

[garciasolero]

I meant that RFC7009 and consent revocation are distinct issues that we should not mix. RFC7009 defines a revocation mechanism by which a client invalidates its tokens. In other words, the authserver verifies whether the token was issued to the client making the revocation request. If this validation fails, the request is refused.

As far as I know, clients are not the masters of the consents to revoke them. Even the operators, the masters of the consents, could not use RFC7009 to invalidate tokens because they are not the client to whom the tokens belong. If it is desired that the master of the consent should revoke tokens associated with a consent, some other analogous mechanism should be defined, perhaps internally, but not the one defined by RFC7009, which is restricted to the clients.

[AxelNennker]

Summarizing: for some permutation of SHOULD vs MUST

1. consent SHOULD be checked when an access token is used at the RS because consent could have been revoked in the meantime.

2. consent SHOULD be checked when a refresh token is used at the AZ because consent could have been revoked in the mean time at the AZ or a telco.

3. if a client wants to revoke tokens, for whatever reason, then RFC7009 should be used. That is Camara AZ MUST implement a token revocation endpoint that implements RFC7009.

4. if users revoke consent at clients, however that is done, then the client should revoke the tokens issued to the client related to that user at the Camara AZ revocation endpoint.

5. if users revoke consent at a telco, however that is done, then the telco revokes ... (RFC7009 is for clients. What now?)

   • if the telco operates the AZ then is somehow revokes the token for that user for that scope and purpose the consent was revoked for.
   • if the an aggregator operates the AZ then ...

[garciasolero]

@AxelNennker,

1. There is no need to check consents on every resource call. That solution is inefficient. Another design alternative is to issue short-lived access tokens, as there is no strong requirement for tokens to be invalidated instantly after revoking consent.

2. OK

3. We would not mind adding the implementation of RFC7009 to revoke tokens for security reasons. But we would not like to be adding new requirements/implementations that have not been requested by the applications and that they do not intend to use. Is there any request from the applications to use it?

4. The consent is captured and storaged by the operators (consent masters), not the applications.

5. The revocation of consents will be carried out through the channels established by each operator, as they are the masters of consents. Therefore, I do not believe there is a need to standardize that flow. My comment in point 1 also applies: short-lived access tokens and checking consents in refresh token requests.

[izahirclemencia]

• There is no need to check consents on every resource call. That solution is inefficient. Another design alternative is to issue short-lived access tokens, as there is no strong requirement for tokens to be invalidated instantly after revoking consent.

If the token is not revoked at the same time as revoking consent, the token may still be used to perform actions on behalf of the user.

Summarizing: for some permutation of SHOULD vs MUST

1. consent SHOULD be checked when an access token is used at the RS because consent could have been revoked in the meantime.
2. consent SHOULD be checked when a refresh token is used at the AZ because consent could have been revoked in the mean time at the AZ or a telco.
3. if a client wants to revoke tokens, for whatever reason, then RFC7009 should be used. That is Camara AZ MUST implement a token revocation endpoint that implements RFC7009.
4. if users revoke consent at clients, however that is done, then the client should revoke the tokens issued to the client related to that user at the Camara AZ revocation endpoint.

5. if users revoke consent at a telco, however that is done, then the telco revokes ... (RFC7009 is for clients. What now?)

   • if the telco operates the AZ then is somehow revokes the token for that user for that scope and purpose the consent was revoked for.
   • if the an aggregator operates the AZ then ...

My take on the summary:

When a user revokes consent at a telco operator or aggregator, all access tokens and refresh tokens associated with that consent MUST be revoked in compliance with RFC7009.

This requirement ensures a standardized and secure approach to consent revocation, making it easy to implement alongside the OAuth standards.

[garciasolero]

Token revocation and consent revocation are distinct issues.

Token revocation can be performed by clients using RFC7009 and will instantly invalidate access tokens, thereby also blocking future access to resources related to that access token.

However, consent revocation has nothing to do with RFC7009 token revocation, it is done by each operator's own channels (not by aggregators or clients) with their internal implementations. Some of them will be able to guarantee the revocation of related tokens at the moment, but others may not, because it would make their implementations very complicated, or because their local legal requirements do not require it. For these cases, it has been proposed to issue short-lived access tokens that can be renewed at any time with a refresh token, as long as the user's consent still exists.

[izahirclemencia]

Token revocation and consent revocation are distinct issues.

Token revocation can be performed by clients using RFC7009 and will instantly invalidate access tokens, thereby also blocking future access to resources related to that access token.

However, consent revocation has nothing to do with RFC7009 token revocation, it is done by each operator's own channels (not by aggregators or clients) with their internal implementations. Some of them will be able to guarantee the revocation of related tokens at the moment, but others may not, because it would make their implementations very complicated, or because their local legal requirements do not require it. For these cases, it has been proposed to issue short-lived access tokens that can be renewed at any time with a refresh token, as long as the user's consent still exists.

I am not stating that token revocation and consent revocation are the same.

My recommendation is to revoke all tokens related to a consent after this consent is revoked.

Briefly explain me your recommendation on how to tackle the scenario where a user revokes their consent and that this is enforced directly. @garciasolero