discussion: OAuth - using OAuth just for authentication

[elarlang]

spin-off from https://github.com/OWASP/ASVS/issues/1916 "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

The question is - should we watch it only as unnecessary overengineering, or as a security problem to open up a new set of attack vectors.

-- Feedback from @tghosth in https://github.com/OWASP/ASVS/issues/1916#issuecomment-2024985876

I agree this is an important idea but the idea needs to be actionable

[csfreak92]

I am not sure what could be our actionable recommendation for this issue though. Maybe as a guide, let's write down the concern from this statement:

security problem to open up a new set of attack vectors.

Got any ideas @jsherm-fwdsec and @TobiasAhnoff?

[randomstuff]

directly OIDC should be used without OAuth overhead

I'm not sure I understand what you mean by that. OIDC is a layer on top of OAuth so …

[elarlang]

My reason to open the issue - OAuth was not built for authentication, but if it used only for that purpose, is it acceptable soluton or over-engineering opens too many security holes.

https://auth0.com/intro-to-iam/what-is-oauth-2

OAuth 2.0 is an authorization protocol and NOT an authentication protocol. As such, it is designed primarily as a means of granting access to a set of resources, for example, remote APIs or user data.

@csfreak92 - I agree, based on my current knowledge, actionable requirement is not a likely outcome at the moment.

I changed the issue title and removed the "proposal" part from this, at the moment the goal is to have a discussion and collect arguments, is it worth having a requirement, recommendation, or mention in chapter texts, or all concerns are covered somehow with other requirements?

@randomstuff - yes, it was bad wording from my side. Including the issue title (modified this one as well).

I have seen too many times, that "authentication decision" or user data is read from an JWT format access token. Access token is not meant for that. Often only every token from the same authorization server is valid - and if it provides tokens to different applications (which is usually the case because this is the entire point of that), every valid token from the same authorization server is enough to authenticate to the application.

So, my goal here is to collect feedback and arguments, is this something that requires further attention or not.

[jmanico]

There is absolutely a use-case to do a flow that includes both an OIDC claim (identity) and an OAuth2 claim (delegation) at the same time.

directly OIDC should be used without OAuth overhead I'm not sure I understand what you mean by that. OIDC is a layer on top of OAuth so …

[csfreak92]

There is absolutely a use-case to do a flow that includes both an OIDC claim (identity) and an OAuth2 claim (delegation) at the same time.

Got any solid examples @jmanico? I think that would solidify the argument if we have some great examples in case there were doubts from the community. :)

[jmanico]

For example you can log into google via OIDC and also provide OAuth2 access to some of your google resources to the given server.

Or the old service Mint may use you your bank as a login provider and also delegate limited access to your bank transactions to Mint's server.

And in generate OIDC serves as authentication while OAuth2 tokens can be limited in scope and provide limited access to resources.

[csfreak92]

And in generate OIDC serves as authentication while OAuth2 tokens can be limited in scope and provide limited access to resources.

This is what I think so as well...

[elarlang]

As here is no material for requirement, I close this.