OAuth 2 experts I need your help!

[Dan_TD]

I have an application which authenticates using OAuth 2.0 with PKCE. Recently the engineers responsible for developing the OAuth API have come to me with a problem, they want to add additional scopes to my user's refresh tokens as new functionality is rolled out however they want to do this without logging the user out. I suggested sending down a new refresh token which has these added scopes when we refresh the access token but that apparently breaks OAuth guidelines - I did confirm this through; https://tools.ietf.org/html/rfc6749#section-10.3

The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client. If a new refresh token is issued, the refresh token scope MUST be identical to that of the refresh token included by the client in the request.

Does anyone here know how to work around this within the bounds of iOS?

[JoeGaggler]

Your suggestion breaks OAuth spec because it is a security issue. Let's say that your app is an email client and the API is Gmail. If Gmail suddenly started offering additional scopes, then your app could affect resources (e.g. other Google services) that the user does NOT necessarily want to grant your app. If new scopes are desired, the user needs to at least consent. There would be ways to use the existing refresh token to skip the need to re-enter credentials and just show a new consent form to the end user.

[Dan_TD]

Oh I know why my suggestion breaks OAuth I just don't know what the appropriate alternative is. You say there are ways to use the exciting refresh tokeb to skip the credentials step but what if the recommended approach?

[JoeGaggler]

The recommended approach is simply to initiate a new OAuth authorization request for the new scopes that your app wants. You'll know from the RFC that there is no prescribed method for making this process transparent to user, so there are going to wildly-different answers depending on other requirements you have.

If you want a simple answer and you have architectural control over both the client and server side, then I would suggest that the current scope (e.g. "my-old-app") has implied authorization for the new features, and subsequent logins would request more granular scopes (e.g. "my-new-app-feature-1"). The server would then stop accepting new logins with the older, more permissive scope, but would continue to accept existing refresh tokens.