oauth related discussions

[elarlang]

It's a nice base from Ralph / @csfreak92 , I try now to push those topics forward and validate some ideas.

OAuth - dependency on web architecture

We don't have a link to "OAuth 2.0 for Browser-Based Apps" which should be probably the most relevant document to follow for ASVS.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps

From risk point of view, it's completely different, is it BFF solution or browser communicates directly with a authorization server.

Discussion/Proposal 1

The summary for browser based communication says:

To summarize, the architecture of a browser-based OAuth 2.0 client application is straightforward, but results in a significant increase in the attack surface of the application. The attacker is not only able to hijack the client, but also to extract a full-featured set of tokens from the browser-based application.

This architecture is not recommended for business applications, sensitive applications, and applications that handle personal data.

Write requirement (preferred) or at least "really strong recommendation" to avoid architecture where the browser communicates directly with authorization server token request and handling access token and refresh token.

Or in OAuth terminology, that OAuth confidential (and not public) client is used.

May be limited to first-party solutions.

edit: moved to separate issue: #1963

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: moved to separate issue: #1964

Discussion/Proposal 3

Probably I was the first one to say that redirect_uri validation is a duplicate of general open-redirect but now I think it's important to have them as a separate requirement:

redirect_uri must be validated with the string-match method, which means no "wildcard" validations.

There are 2 parts:

• Authorization Server must not accept anything else than (one of) the precise URL from the pre-registered list
• As a precondition: the OAuth Client must not send business logic URL to the Authorization Server. It is pretty much the same as Referrer leakage.

edit: moved to separate issue: #1965

Discussion/Proposal 4

There is a clear trend of overengineering using OAuth. One of them is using OAuth only for providing authentication. In this case, directly OIDC should be used without OAuth overhead.

Also addressed here: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-7.1

edit: moved to separate issue: #1966

[tghosth]

Discussion/Proposal 1 - that sounds like a sensible extra requirement for L2 and L3
Overall it seems like things in Section 7 are to be banned altogether and the Browser-based OAuth 2.0 client.

Discussion/Proposal 2 - If this is a simple requirement then it sounds sensible as long as it is not too detailed.

Discussion/Proposal 3 - Suggest you propose an updated/added requirement.

Discussion/Proposal 4 - I agree this is an important idea but the idea needs to be actionable

[elarlang]

ping @jmanico - I would like to get your opinions as input to move further

[elarlang]

I opened separate issue for each topic and close this issue:

• proposal/discussion: OAuth - disallow web application to be OAuth public client (and to have direct communication with OAuth token endpoint) #1963
• proposal/discussion: OAuth - (for 1st party usage) only used (by the client) communication options must be allowed by authorization server #1964
• proposal/discussion: OAuth - separate requirement for redirect_uri string-match registration and handling #1965
• discussion: OAuth - using OAuth just for authentication #1966