oauth related discussions
elarlang opened this issue · comments
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.
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_accessmay be worth special mention
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.
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
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