In docs, Dynamic scopes is presented as follows:
Dynamically. You configure an OAuth 2.0 client with a comprehensive list of scopes and resource owners authenticate against it. When AM receives a request for scopes, AM's Authorization Service grants or denies access scopes dynamically by evaluating authorization policies at runtime. Therefore, two different users requesting scopes A and B to the same client can receive different scopes based on policy conditions.
With a further comment in the AuthZ guide:
When OAuth 2.0 policies are configured, default scopes are granted in the following situations as long as they are configured in a policy which passes policy evaluation:
- When no scope is requested
- When default scopes are requested
The second comment specifically made me understand that scopes were granted only if there was a policy granting them, and I understood it as having the Authorization server is the policy decision point. That is in line with the way we use the policy engine to design authz policies and how IG and policy agents understand it too. If no policies is defined, access is denied. That is in line with the comment above. However I found out that the comment in the docs above is only valid for some of the flows (e.g. ROPC) but not others (the authZ code will return the scope if consent is given, even if there are no policies defined for it).
This is because the policy engine is being used differently in the context of Dynamic scopes. Talking to engineering, the following comment was made:
I believe the above needs clarifying in the docs to avoid the confusion.
There is also a need to document the difference in outcome depending on the flow. The difference is due to the fact that some flows don't let the user express their consent (ROPC).
- Create a OAuth2 environment with scopes read and write
- Enable dynamic scope
- Create one policy to deny the 'write' scope to users who are not part of the 'editor'
- Request the scopes 'read' and 'write'
1) As far as I can see, with ROPC you will never get the scopes as there is no consent possible and no policy to imply consent for those.
2) With AuthZ code, the RO will see a consent screen with read if not an editor, and with read and write if they are an editor and the scopes will be granted if consent is given.
Note that I haven't checked all flows and configuration.