4 ms·
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 t
by eterm 2y ago
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.
- PedroBatista 2y agoThis. At any big company, if you’re doing software you’ll be doing OAuth/OIDC like it or not.
- zwnow 2y agoSo 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.
- eterm 2y agoOIDC 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.
- zwnow 2y agoWhy though? Why are devs so afraid of auth?
- eterm 2y agoI'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.
- zwnow 2y agoSo 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?