More details on obtaining tokens for existing grant use case

[Nikola Kramaric]

Obtaining new tokens for existing grants

Clients can also obtain fresh access and, optionally refresh tokens based on existing grants if they re-issue an authorization request, reference an existing grant and follow the rest of the authorization code flow.

The following use case is outlined in the grant management spec but, for me, it is unclear how one would obtain new tokens for an existing grant_id. The parameter grant_management_action has the following options: create merge replace. Is the use case above achieved by not specifying a grant_management_action and only passing a grant_id?

Also, would the client application be required to pass the same scopes and authorization_details to the /authorize endpoint order to retrieve new tokens for an existing grant or would they need to pass those parameters if the intent is just to retrieve new tokens?

Just to provide a bit of context on my request. We are thinking about the use case where refresh tokens have expired even though the grant may not have expired (assuming we there is some sort of grant/consent expiration). In this use case we are not editing the consent in any way (merge, replace), we simply want to get new tokens for this grant. It would also be nice to have some guidance on when to show the consent acceptance screen in this use-case, although OAuth provides no such guidance. I know IDPs have implemented parameters like prompt.

‌

[Dima Postnikov]

Thanks Nikola.

Re: use case.

In general, FAPI WG recommends not to use refresh token rotation with FAPI profile for security purposes. From interoperability perspective this also creates additional complexity for everyone involved.

If refresh token rotation is utilised in a particular ecosystem, the actual mechanism would be to receive a new refresh token from a token endpoint (e.g.), assuming that refresh token is still recognised by the AS and the grant is still active.

Re: re-authorization

From grant management perspective, we wanted to avoid a scenario when grant_id is used instead of refresh token or in a same way as refresh token. This is why we specified that a client might be able to get tokens re-issued but it needs to initiate another authorisation request.

It’s left up to AS to decide if a user needs to prompted or not (or just like you mentioned use parameters like prompt).

All request parameters need to be re-specified, so it’s just like a first request. Pretty sure the intent was to keep it simple until we have a compelling use case to change it.

Client can specify what i wants to happen to an existing grant (e.g.: merge or replace) or default AS behaviour can be triggered (this could be ecosystem specific or AS specific).

Current specification mandates grant_management_action parameter when grant_id is specified in the authorization flow.

In case the grant_id is provided and the action is not specified, the authorization server shall respond with an error code invalid_request.

Alternative way to capture a new user authorization for about-to-expire grant is to use CIBA flow.

Perhaps this is the way to clarify some these points:

Obtaining new tokens for existing grants

Clients can also obtain fresh access and, optionally refresh tokens based on existing grants if they re-issue an authorization request with all request parameters, reference an existing grant, specify grant_management_action and follow the rest of the authorization flow (either redirect or decoupled).

‌

Let me know what you think?

[Nikola Kramaric]

Thank you for the clarification.

The scenario here is that a refresh token might expire after one month but the user might have consented for one year.

It might be difficult to recommend that refresh tokens should last as long as grants or not to use token rotation due to various existing AS implementations. Also, refresh and access token management to me falls under the security domain while the grant management is more in the business domain if that makes sense?

In this example we end up in a situation where a consumer has granted permissions for one year but refresh tokens have expired and the client application essentially has a zombie grant. It might be reasonable to have a grant_management_action for this use case. I don't think this scenario is the same as a refresh token scenario. By initiating an authorization flow we are telling the AS that we need new tokens and might need user action to confirm whereas refresh tokens never require user action. The AS can decide whether the consumer needs to re-accept consent or do it silently through redirects depending on prior activity on this grant.

The short of it is that I agree with your update in the wording and it provides more specificity. However, I am not sure the existing grant_management_actions cover this use case.

[Nikola Kramaric]

Hi Dima, as a summary from the conversation from the call, you were going to think about whether to specify the action that best accommodates this use case which would be merge. So the text could be modified to:

specify merge as the grant_management_action and follow the rest of the authorization flow (either redirect or decoupled).

Separately there was a debate as to whether this use case should be supported at all. That can be raised in a separate issue and we can close this one out with a PR if you are good with that?

[Dima Postnikov]

PR created: https://bitbucket.org/openid/fapi/pull-requests/391/clarification-re-new-tokens

[Dima Postnikov]

PR merged

[Dima Postnikov]

PR merged