Is it satire because many of the buttons and links don't work so you can't actually finish anything?
If it’s serious, I doubt it provides much real value. Developer experience is built on accomplishing actual tasks, not the surrounding administration and ceremony. Aspiring devs should probably work on personal/toy projects or open source.
Whats good about OAuth if you dont require Authorization though? Most apps I know of mostly only need Authentication. Never implemented it myself so I really want to know
Often when people ask for Oauth they really mean OAuth2/OIDC, and what they really want is managed authentication, with further authorisation being managed at the application level rather than through oauth.
The advantages are there:
1. Reducing sign-up friction. Despite how much this crowd dislike such things, it's much easier for most people to hit "Use google login" or "use facebook login" than create a new account. One less password to remember ( or one less place to store the same password you use everywhere ) for people without password managers.
2. People trust "Google" or "Facebook" more than they trust random service they're just checking out. Having that "sign in with google" extends that trust to your service.
3. If you ever do need Authorization, it's much easier retro-fitting that if you already have OAUTH than trying to retro-actively fit it all to get that authorization.
4. Letting someone else take care of user account cancellation. Businesses hate it when there's no OAUTH, because they don't want to have to track down and change / cancel accounts when someone leaves their organization. They want to suspend/remove them from their Azure AD / Octa / etc and that user instantly becomes persona-non-grata across all services. They might also want to have different groups at their end, so they're still the same identity, but lost authorisation to log into <Service> now they moved from an ops role into development, for instance. They're still the same identity and same authenication in this case, but should no longer be authorised for your service.
So for the sake of simplicity devs offload authentication to some 3rd party provider? Oauth/2 is for authorization though, i dont get where the authentication part comes from. They even write it is an authorization protocol.
OIDC describes itself as: "OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework".
So Oauth2/OIDC is what you typically want?
I don't really understand the details well. I understand what vendors and customers are after. I wouldn't ever try to write any clients/servers myself for this stuff.
I'm not afraid, I just don't understand the nuances well enough.
But it's also easy to understand what there is to be scared about:
1. Security critical.
2. Single source of failure. ( If your auth fails, it doesn't just break one feature or aspect, it takes everything and everyone down with it. )
3. Performance critical. It's a bottleneck in most applications, it's very rare and even more difficult to get distributed auth working, if you factor in repudiation / token cancellation.
It's not an area you can "fake it 'til you make it" or "move fast and break things" with.
Even just "buying" the solution isn't easy. Actually implementing your own OIDC client/server solution is a large project that only makes sense to dedicate a team to in the largest of organisations.
So how are hobbyists handling auth in their hobby projects? I am sure they cant commit to using OIDC if its that difficult to implement? This is something I try to understand since almost 2 years... Are they just using jwts?
Maybe I'm zooming in too much on semantics here, but I have a hard time imagining an application that needs authn, but not authz. Even editing your own preferences requires authz, as other people shouldn't be able to do that.
In any company of any non-trivial size, and even many smaller ones, authorization is a big deal that tends to permeate all the systems. For example you don’t want most staff to be able to log into the payroll system and change salaries. But they can log in and look at their own records. That behavior requires authorization either way.
If you then add outside people or companies to that, it becomes even more complex. Most companies aren’t in the business of implementing their own distributed auth system, and wouldn’t be able to do a good job if they tried. So they buy an implementation of a standard system like Oauth.
The "their own" part of your statement is what some (many?) consider to be in the authorization domain.
Discussions around Auth are typically confusing. This is not helped by authentication and authorisation sounding similar, but also because it is difficult to keep track of whether what is being discussed is first party or third party.
Most apps don't need third part authorization, although some do. For example if I were to use Cisco Meraki Oauth, then the third party authorization of which parts of the network were visible to me as a service is critical.
On the other hand, if I'm just using them as an easy way to provide authentication for a service which I only want to target to Meraki customers, then I don't care about the third party authorisation, and just need the authentication part. I still need first party authorization on my own system to keep different users' preferences separated.
Another source of confusion also mixing discussions of intra system authentication + authorization with external authentication + authorization. I've seen lots of discussions of JWTs for example which quickly start talking about local services, whcih might be better handled by not having the user involved at all, and just having a secured pipeline between services. You often don't need to have passthrough authentication/authorization, although again there are advantages and disadvantages to organizing services in this manner.
If it’s serious, I doubt it provides much real value. Developer experience is built on accomplishing actual tasks, not the surrounding administration and ceremony. Aspiring devs should probably work on personal/toy projects or open source.
That said, it looks great—well done!