proposal/discussion: OAuth - (for 1st party usage) only used (by the client) communication options must be allowed by authorization server about asvs

[elarlang]

3 Verify that client configuration asserts least privilege (e g scopes and flows)

I was thinking more about it - I think it is another topic compared which I opened, so probably we have 2 different vectors to cover.

• original issue - (at least for 1st party solution) authorization server should accept only those parameters and values for communication, that are needed by the (one and only) OAuth Client - response_mode, response_type, scope
• additional issue, by Tobias - scope definition on the Authorization Server side for the OAuth Client should not give more permissions than needed for given client and actions.

ping @TobiasAhnoff - please confirm my understanding

[jmanico]

Based on the typical OAuth registration and "user" workflow, I would add one more level here.

1. Server allows a series of scopes to start with.
2. Client registers (once) with a limited list of these scopes (or all that the server offers).
3. A "user" goes through the OAuth flow and may only use the scopes that the server approved of during registration time and NOT NECESSARILY the complete lists of scopes that server allows. Again, only the scope the server approved of during client registration should be allowed during user flows, and I feel we need to clarify that level of strictness.

So I'd suggest two requirements around scopes since there are granted at very different parts of the OAuth lifecycle.

1. Only let a client register for scopes that the server allows
2. Only let a "user" use scopes the authorization server approved of during client-registration

[elarlang]

I'm not sure we are talking about the same thing here (user registration vs configured client), I modified initial issue to be more clear and added:

edit: scope in mind - authorization request from OAuth Client to OAuth Authorization Server

For the 1st party solution (if there is no "discovery" in place), when an application uses the SSO service from the same organization, there should be no client registration available for being a OAuth Client. It is actually worth a separate requirement.