discussion: OAuth - using OAuth just for authentication about asvs HOT 7 OPEN

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.

from asvs.

from asvs.

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.

from asvs.

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?

from asvs.

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 …

from asvs.

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. :)

from asvs.