The current state of authentication consumes massive amounts of time, money and effort on any given development platform. The author's advice is great, but Oauth2 is absolutely not the end state for distributed identity, and the new thing can't come soon enough.
Puh the article has the same problem as auth always has: lots and lots of magic words which are hard to remember what one word exactly means.<p>We just use keycloak everywhere and I don't know if our setup uses oauth, sso, jwt,oauth2, open id, saml etc.<p>Keycloak library works, configuring Google as an additional provider is easy.<p>I trust that setup but it would be great if we would just have one thing with x features and everyone supports it.<p>You want to connect Fe with be? Use a.<p>You need API token/auth, use b.<p>You want to allow auth from ext? Use c.<p>What I will not do though, auth as a service. I add Google and co because the customer is thrusting them.
OAuth2 and Open ID Connect (and FAPI) underpin the design of both the UK and Australian Open Banking systems. The Australian design (Consumer Data Right) is even starting to extend into other sectors beyond banking, such as Energy and Telecommunications, where "Data Holders" (sector specific companies, think your bank, your power company, your telco etc.) must become identity providers so consumers can log-in and grant access to new third party products (Data Recipients) who will provide value added services on top of your data (account aggregation, bill smoothing, who knows) via standard APIs. This is reflected in law and compliance is monitored by a government agency.<p>Other countries are watching these examples before undertaking their own versions.<p>The future could be built on it.
Can't agree more with this article! How I see it, the trend is to have different servers for the front and the back and to link them with OIDC, but that's so painfull to implement and with lot of downsides for only a few benefits (at least with the back in .Net, I don't know about other).
The problem with oa2/oidc is client integrations on the client side.<p>Many commercial offers, but in reality on the foss side they're a major PITA.
At least if you're looking for a painless solution in the hybrid app world aka it should work for web and mobile with the same codebase.<p>I'm using Keycloak but keycloak adapter 'cordova-native' isn't working and you need deep links which are no longer maintained etc. It's a mess.<p>If you're just looking to secure your HTTP APIs or your SSR or classic site, there are many working and simple options, but on the presentation side it's a fugly mess.
There's quite some cargo cult – e.g. jwt and oauth2 often appear like that, when a simpler design is discarded because 'that's the way'.<p>If you can design a system without accounts (shortly here on HN), you won't miss oauth2.
Oauth2 is commonly used to protect APIs. It's very simple in that mode. Use your credentials (user password or whatever) and get a token with some expiry time and use it. When it is about to expire, get another one via a refresh API. Most well known REST APIs have used this for the last 12 or so years and it's not hard to implement even without a lot of library support. Most importantly, it follows the principle of the least amount of surprise. People who have used web APIs before, will have likely dealt with this before. I've been building APIs with some form of OAuth2 api protection for many years. Its a very standard thing at this point. I've also used NTLM and OAuth1 tokens for this in the past. Simple HMACs also used to be a thing with e.g. xml-rpc. And before that people just passed around session cookies; which especially over http had some obvious security issues.<p>These days, many APIs are stateless and there is no server side session. There's just authentication tokens. These tokens may be random numbers, some kind of signed token, or a JWT. Which it is does not really matter for the user. It's just an opaque string. In the case of JWTs the string might be a bit long and contain some data.<p>The notion that OAuth2 is not about authentication is kind of a half truth. You use your user/password or some other credentials to get a token via one of its flows. So, that is an authentication process of course. That token gives you access to an API. That's technically authorizing access. However, when you make requests to an API that is stateless, it's also a form of authentication. It does not know who you are until it inspects the token. The process of verifying that somebody is who they claim to be is usually called authentication. And a typical OAuth2 API will do that by verifying the signature of the token.<p>The token might also include information as to what they are actually authorized to do (e.g. via a scope or some other sort of claim in a JWT). But that is optional. I typically use role based security and I don't rely on tokens to transmit any information about which roles a user has. That is simply looked up from a database when the request comes in and used to determine which of a very long list of privileges they have. We assign roles to users and we verify privileges to authorize their access. If an admin assigns new roles to a user, their tokens are still valid but they are now authorized to do different things with it. So arguably, it's an authentication token and not an authorization token if you use it like that. The actual authorization is based on what roles you have. The token does not include any information about that. It just confirms that the user is who they claim to be. It could include that of course and with some APIs that is a thing. But with ours it just isn't. It's just an identity proof and we use it exactly like we would use a user password combination: we verify it is correct and valid.<p>Most modern apps don't have a notion of server side sessions. That's a thing from late last century and the beginning of this century. You can still do that of course but it's just less common unless you use stuff like ruby on rails or some older php frameworks.<p>But most full page applications or mobile applications talk to APIs using tokens. If your app is like that, I'd argue that you'd pretty much should support oauth2 unless you have a really good reason not to. And that that is not such a big deal. Not all of it but just the handful of the flows related to getting a token via the login flow and (optionally) refreshing it. The simplest way to get a token is basic authentication over https. You can implement a few variations of that that e.g. use a basic authentication header; a post form; a json API, etc. The standard is not particularly concerned with naming and form of things unfortunately. That's always been the issue with OAuth; there's too much freedom with respect to naming things, what to actually send over the wire, etc. Using the token usually means passing an Authorization header with as the value "Bearer xxxx" where xxxx is the token. But I've also seen APIs where they simply shove that in a post parameter, the json or even the url. As a standard OAuth2 is both very complex and unders pecified. But the good news is that the easy parts of it are all you need. It's all the less common flows that you probably should not worry about because you don't need them.<p>OpenID Connect has the similar issues. Very common if you want to add a e.g. Github or Google authentication flow to your website. It's a bit better standardized but still with a lot of annoying vendor specific variation in each implementation. And it may or may not include authorization information. Technically the tokens you end up with are either used as OAuth2 tokens or used to get one. It's ultimately just a convoluted way to get an OAuth2 token.
OAuth2 was designed in a time when everybody thought consolidating logins would be wise, and just use Google / Facebook / Microsoft accounts to login everyhwere.<p>OAuth2 was production ready when everybody realized having FAANG logins is insane, as they use it to massively track you on websites that else would be beyond their reach. And since reports off random FAANG account shutdowns, it is even wise not to use them when you are okay with tracking, as suddenly a handfull of FAANG megacorps have the power to shut down your digital life with a click.<p>So here we are, having to deal with massive protocol overhead for a feature most of us don't want anymore.
I'd rather use an over engineered solution that has lots of libraries available for implementation than to build a home baked auth solution that's based off of ignorance.