- Issue created by @paul121
- @paul121 opened merge request.
- πΊπΈUnited States paul121 Spokane, WA
Attaching screenshot of what this looks like. The scopes field is available below the 3rd party/confidential fields, but before Redirect URIs.
- Status changed to Needs review
about 1 year ago 6:42pm 1 November 2023 - First commit to issue fork.
- Status changed to Needs work
about 1 year ago 2:19pm 3 November 2023 - π³π±Netherlands bojan_dev
I made a few changes to support the default scopes in all grant types. Remaining tasks:
- Check if we still need the default scope logic in the ScopeRepository::finalizeScopes.
- Add tests for all grant types.
- π³π±Netherlands kingdutch
I just want to note that this is not a bug but rather a feature request (though I'll leave changing the category to others if you agree).
As already shown in the issue summary:
If the client omits the scope parameter when requesting
authorization, the authorization server MUST either process the
request using a pre-defined default value or fail the request
indicating an invalid scope. The authorization server SHOULD
document its scope requirements and default value (if defined).In the initial implementation we specifically chose to go for the "fail the request indicating an invalid scope" route.
In any change we make to this we should ensure that the module can be configured to disallow the use of default scopes and force clients to request some.