enable using default scopes from authorization server

[natergj]

OAuth allows for the authorization server to provide default scopes when no scopes are specified by the requestor as described in https://datatracker.ietf.org/doc/html/rfc6749#section-3.3

This allows for the library to be configured to rely on the default scopes.

Closes/fixes # n/a

Checklist

• [x] This PR makes changes to the public API
• [x] N/A I have included links for closing relevant issue numbers

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 80.56%. Comparing base (f0ad76e) to head (f4d11e0). Report is 78 commits behind head on main.

:exclamation: Current head f4d11e0 differs from pull request most recent head c192e45

Please upload reports for the commit c192e45 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1405      +/-   ##
==========================================
+ Coverage   80.53%   80.56%   +0.03%     
==========================================
  Files          45       45              
  Lines        1731     1734       +3     
  Branches      344      347       +3     
==========================================
+ Hits         1394     1397       +3     
  Misses        299      299              
  Partials       38       38              

Flag	Coverage Δ
unittests	80.56% <100.00%> (+0.03%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[natergj]

@pamapa looks like this won't be part of the 3.1.0 release? Are there any updates or anything else I can do on this PR to help get it merged?

[pamapa]

@pamapa looks like this won't be part of the 3.1.0 release? Are there any updates or anything else I can do on this PR to help get it merged?

Good that you ask. Do you have an actual use-case why you would need such a feature and let us know? You will also need to rebase against main, as it as now merge conflicts.

[natergj]

Good that you ask. Do you have an actual use-case why you would need such a feature and let us know? You will also need to rebase against main, as it as now merge conflicts.

Ah. missed the merge conflicts. Those are resolved now.

there are three use cases we are interested in for the default scopes

1. The issue we are starting to run into with some of our clients is request urls are too large due to a very long scope search param for scopes being requested and the requests were being rejected. The APIs our web apps interact with use very verbose scopes and we need to request a lot of them so our query string becomes very long. By using default scopes, our requests to the IDP will be reduced in size significantly without needing to make additional adjustments to our hosting infrastructure.

2. Our web application teams have been provided with a process to request new allowed scopes for their web applications. The web application must then be updates to request the newly allowed scope after it is added to the client. If a web app begins requesting the scope prior to it being approved, all subsequent authentication requests fails and a deployment must be rolled back. It is our hope that the default scope will help to alleviate the human error as the web apps will not become out of sync with their requested scopes.

3. Our mobile app uses a graphql interface. Our API teams are updating the REST APIs that back the graph. These updates will often require a new or different scope to be included in the authorization token. Default scopes will allow that work to continue without the need to deprecate and replace the graphql schema or forcing our users to continuously be updating the mobile app.

[natergj]

Thanks for your time and help with this @pamapa ! It's greatly appreciated

[pamapa]

Thanks for contributing!