Why is OAuth still hard in 2023?

Thank you! Not sure, just part of the orange site mystery~

Your `onlogin` callback will only ever be invoked by the SDK on successful login. So the data coming thru there is always the result of the OAuth flow itself. For MPAs, you can create your own document cookie and/or modify local/sessionStorage, and then every new page load will pull/load from those storage systems. SPAs can & should do the same – they just have the added benefit of keeping in-memory state alive.

As for POSTing to your backend, the same XSRF/CSRF/CORS rules & mechanisms apply as with any other client->server transaction. You can rely on CORS for limiting who can talk to your API, you can pass along a unique token for CSRF prevention, and/or come up with your own Authorization header format.

Soon I'll be adding a `redirect_uri` config option for all btn.social apps. Much like the normal `redirect_uri` in OAuth, this will be a target URL that btn.social redirects users to post-login. This will enable server-side redirects, which means that your API just has to verify the "login.btn.social" referer.

> it is true that majority of people I interacted with are having troubles understanding these protocols. However, what I can attest to is that they're also extremely underwhelming as people working in IT, with bad work habits and misplaced focus. It's impossible to explain or clear up the protocol to such audience because they lack much more when it comes to knowledge and discipline.

In my experience, IT generalists are dealing with a thousand problems, and that has little to do with misplaced focus and more to do with the fact that management just spent $$$ on this new platform and needs it integrated with internal systems, and they're encountering this OAuth thing out of necessity.

Part of the reason my training materials were successful within that community was because they distilled all of the usual questions about how and why someone would use OAuth relative to the platform and presented essentially a menu of recommended options to be explored further depending on their use case.

And people found success with this approach because it helped them solve their very immediate and concrete problem while also explaining why the approach solves that problem.

> You can't force knowledge into audience who can't or refuse to understand it, so there's no point in even trying to do it let alone draw conclusions how the protocol is hard, confusing or difficult when there's whole knowledge void in other pre-requisite areas.

Different people have vastly different learning styles, and some people just don't do well if you hand them a dense specification. Working from concrete use cases can be far more productive since it meets users where they are and gives them a pathway to understanding how their use cases connects to the OAuth concepts.

In a perfect world, everyone who works on auth would be experts. In the world we have, quite a few people have no choice but to do their best to learn the subject matter to solve the problem at hand.

Unfortunately this also leads to quite a bit of confusion and some really problematic OAuth implementations.

It's not particularly hard, this article is just self-serving content marketing because their product is an OAuth wrapper.

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.

I've been using WorkOS for my SaaS products and I'm pretty satisfied with it. It's straightforward to set up Google/Microsoft/MagicLink (free), including staging and production environments. The best part, though, is that it lets my enterprise customers configure their own SAML/OpenID Connect IDPs.

I get charged per connection, so I just pass that cost onto my customers. As a solo developer, I'd have a hard time supporting so many IDPs with a unified API without this.

They did recently hike up the cost per connection, but they're giving a one-year extension at the old rates, which seems fair.