undefined | Better HN

0 pointscodebje3y ago0 comments

Dynamic client registration is standardised (https://www.rfc-editor.org/rfc/rfc7591.html), the authorization code flow is standardised (https://www.rfc-editor.org/rfc/rfc6749.html). The device authorization flow is also standardised (https://www.rfc-editor.org/rfc/rfc8628.html). The preferred desktop app authorization process is described in a best current practice document (https://www.rfc-editor.org/rfc/rfc8252.html). A metadata URL for auto-configuration of OAuth2 Authorization Servers is specified (https://www.rfc-editor.org/rfc/rfc8414.html). How to validate an access token, which also lets you know if you need to refresh it, is specified (https://www.rfc-editor.org/rfc/rfc7662.html via an API endpoint, https://www.rfc-editor.org/rfc/rfc9068.html for JWT tokens) - or just use it, and if it fails, refresh it.

It's fully specified. It's well implemented - you'd have to go out of your way to find an authorization server that doesn't do everything above, with the exception of dynamic client registration, because that's not intended for clients but rather for integration with developer portals and similar. Google Auth and Amazon Cognito don't support dynamic registration for third parties, eg, because if you're doing dynamic registration it'll be because you're operating your own AS - Okta, Auth0, and Keycloak all support it.

There's also plenty of good generic OAuth client libraries. Spring Security, the oauth2 crate for Rust, etc.

0 comments

2 comments · 1 top-level

smackeyacky3y ago· 1 in thread

Just because the standards exist doesn't mean everybody follows them. Most and maybe all implementations have some crazy customisation. It makes the standards and docs almost worthless.

jeroenhd3y ago

But that's hardly OAuth's fault. I can blame HTTP/2 cleartext because none of the websites I'm trying to access are working in my browser, but it's not reasonable to blame a generic protocol for not providing my niche when it's the implementations that are broken. Imagine complaining to the WHATWG because Microsoft decided to host an IRC server on port 80 and none of my browsers work.

In my experience, OAuth works great. Standard libraries Just Work, login Just Works, all you need is a URL (usually standardised) and maybe the configuration the service is expecting (i.e. the names of the permissions you're asking the user for). Usually, that's nothing special to set up. In some cases, particularly with huge "fuck you we're big enough to be the standard" vendors, there are some stupid hardcoded values and workarounds you need to deal with because they couldn't be bothered to use a library or document their flawed implementation.

I've set up a Keycloak server and authentication against it is super easy to set up. Copy-paste a domain, two generated tokens, and maybe a URL if .well-known discovery isn't implemented by the client, and that's it. Things can be easy, companies providing "OAuth" support just choose to make your life hard.