- Over time, the API surface covered by the user authorization grant is expanded without further consent from the user
The default strategy will merge scopes that have the same name. So if new scopes are registered with a pre-existing name then the same situation occurs.
- A module has registered a scope: BLOGS_READ
- Portal User grants an OAuth2 Application the scope: BLOGS_READ
- A new module which bring enhanced features is deployed and this introduces a new scope also called “BLOGS_READ” which is required to access its new API
- The OAuth2 Application is now able to also call the new API without needing to ask the Portal User for consent
- The OAuth2 Application should not be able to call the new API without first obtaining further consent from the Portal User
- However unless the OAuth2 Application was incorrectly configured originally (missing scopes), the application will not contain any code for calling the new API
- Only when the OAuth2 Application is upgraded might it need access to the new API. At that stage the OAuth2 Application Administrator can merge the new BLOGS_READ into the existing BLOGS_READ scope, by modifying the OAuth2 Application configuration
- The OAuth2 Application should then redirect the user to the Authorization Service and it should list all the scopes that are merged into the BLOGS_READ scope, including the new one, so the Portal User can provide consent.
- The description of the new scope should be meaningful to the user so that it is clear that something more/different is being asked for