I kinda disagree. Authentication is at OAuths core. You still need to authenticate to obtain a token and in more complex setups you don’t use it for authorization at all because tokens are stale immediately after issuing them. It’s why things like Zanzibar and OPA have been made.
It’s really not. OAuth makes zero assumptions about how you login - granted, the client credentials flow is a form of authentication if you will, but for the user perspective, OAuth starts when you’re signed in. That’s also why you can easily combine it with all kinds of authentication providers.
> OAuth makes zero assumptions about how you login
Neither does OIDC: "The methods used by the Authorization Server to Authenticate the End-User (e.g., username and password, session cookies, etc.) are beyond the scope of this specification."
OAuth makes zero assumptions about a lot of things, like even how you "authorize". That doesn't mean that authentication doesn't play a crucial role. While it doesn't specify how you authenticate the user it still specifies that you must authenticate the user. Outside of the authorization code flow, other flows strictly mandate that you should authenticate the clients.
1. It's not an authentication protocol, but it was abused as one for until OpenID Connect came along
2. OpenID Connect is the compatible authN protocol, and it actually has a spec unlike OAuth2
Both of those are annoying because they are over-complicated for simple use cases and for a long time there were very few simple open-source providers that weren't hiding all the important stuff behind their enterprise/cloud versions.
Open source options like Zitadel are improving this space somewhat, though they are still sort of painfully complicated if you want to deploy something small and simple that you can understand. In order to be big business they have to support tons of 3rd-party provider plugins with all their out-of-spec wrinkles.
It would be nice to have something like Zitadel that is signficantly less concerned about all those third parties - like let me very easily just host username/password and passkey auth in a small package.
OAuth2 is about a billion times better than SAML. At least you have a decent chance of doing it securely if you follow the spec vs about zero chance with saml.
stuaxo · · focus · HN ↗
Oauth2 is utter utter shite as well.
7bit · · focus · HN ↗
vips7L · · focus · HN ↗
9dev · · focus · HN ↗
vips7L · · focus · HN ↗
9dev · · focus · HN ↗
vips7L · · focus · HN ↗
Neither does OIDC: "The methods used by the Authorization Server to Authenticate the End-User (e.g., username and password, session cookies, etc.) are beyond the scope of this specification."
OAuth makes zero assumptions about a lot of things, like even how you "authorize". That doesn't mean that authentication doesn't play a crucial role. While it doesn't specify how you authenticate the user it still specifies that you must authenticate the user. Outside of the authorization code flow, other flows strictly mandate that you should authenticate the clients.
skrtskrt · · focus · HN ↗
1. It's not an authentication protocol, but it was abused as one for until OpenID Connect came along
2. OpenID Connect is the compatible authN protocol, and it actually has a spec unlike OAuth2
Both of those are annoying because they are over-complicated for simple use cases and for a long time there were very few simple open-source providers that weren't hiding all the important stuff behind their enterprise/cloud versions.
Open source options like Zitadel are improving this space somewhat, though they are still sort of painfully complicated if you want to deploy something small and simple that you can understand. In order to be big business they have to support tons of 3rd-party provider plugins with all their out-of-spec wrinkles.
It would be nice to have something like Zitadel that is signficantly less concerned about all those third parties - like let me very easily just host username/password and passkey auth in a small package.
bawolff · · focus · HN ↗