Consent screen is only skipped for the same scope set as the last token

[powelski]

Currently, the consent screen is skipped only if we request the exact same scopes as we did for the previous token. I think it could be improved to only display consent screen if there is a new scope requested. In other words, a scope that is not present in any active token for this user.

Example: now, if we previously granted scopeA, scopeB and scopeC to some app and then have another token requested for scopeA and scopeC, the consent screen will be displayed. But if we request a token for the exact same set of scopes (scopeA, scopeB, scopeC), the consent screen is skipped. Also, if after accepting token for scopeA, scopeB and scopeC we accept another token for scopeA and scopeC, another token request will only skip consent screen for scopeA and scopeC set. I don't see why would we want to skip the consent screen only for the exact same scope set as the last token we requested.

[driesvints]

Can we first check if this conforms to the OAuth2 spec?

[driesvints]

@Sephster what's your take in this?

[Sephster]

The mechanism that @powelski is describing, is the same way that refresh tokens work. You can request the same scopes or fewer scopes (all must be included in the original access token request), but you are not able to request additional scopes on a refresh token. However, this is only applicable to a refresh token and not a request for an access token.

To strictly conform to the OAuth 2 spec, I think we should probably be asking for consent every time. There is nothing in the spec about skipping consent if the same client asks for the same scopes again and has previously been approved.

I'm not a hundred percent sure but I suspect working in this manner might risk a slight security issue. I don't think the system should be assuming that consent is given at time x because it was previously given at time y. I'm not familiar with the feature so don't know if there is an expiry time on this behaviour or not, but this would mitigate the risk somewhat.

If the auth code grant is being used, I believe it should always be the user that gives consent to the client.

[driesvints]

@Sephster so you'd recommend to never skip? We'll need to adjust some things then?

[driesvints]

I'm going to close this because we haven't gotten any other requests for this. Will be happy to look into this again if it ever becomes a bigger issue.

[powelski]

This is much of an issue in apps with many scopes, which are granted gradually. I believe Laravel Passport is not too often used heavily, or is used just as it is, with asking for permissions all the time. OAuth 2 can do better.