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

[elarlang]

spin-off from #1916 "Discussion/Proposal 2"

For a situation, where OAuth is used as a "first-party" authorization solution and the application needs one and only way how it communicates with the authorization server, then for the OAuth client must be configured and the Authorization Server must validate, that: only the expected values are allowed, that is implemented by the client:

• response_type
• response_mode
• scope - here, support for the offline_access may be worth special mention

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

--
Feedback from @tghosth in #1916 (comment)

If this is a simple requirement then it sounds sensible as long as it is not too detailed.

--
Overlap by recommendation from @TobiasAhnoff in #1925

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

Although response_type and response_mode are not directly privilege, those are all related with allowed flow.

[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.