6 ms·

It's amazing how far adrift the industry has gone with authentication. This post is saying to avoid OAuth and use bearer tokens because OAuth is too complicate

It's amazing how far adrift the industry has gone with authentication. This post is saying to avoid OAuth and use bearer tokens because OAuth is too complicated. I agree with OAuth being too complicated, but I don't really think bearer tokens are the solution either. Now there are jwts, and passkeys, and all these other solutions, which from where I'm standing, just look like someone else's resume-builder that I'm going to have to understand in a few years in order to do something simple and unrelated. We are already connecting over TLS, just have the client authenticate with a long lived asymmetric key. Let me see that key in whatever web framework; I should have access to it, same as an HTTP header. Then I'll stick it in the database, maybe hash it first, if it's big. It doesn't have to be harder than that, your identity is (the hash of) your public key.

AlphaSite 3y ago
JWTS (and related token type approaches) are a solution to the whole: how do I avoid spending time doing authn on every request?
dilyevsky 3y ago
If you use mTLS client identity is proven cryptographically (normally via /CN x509 field) - no need to exchange the key during authentication. You still need to generate it and distribute it to the user and manage its lifecycle which gets you to the same place as OAuth except with worse library support
- brendoncarroll 3y ago
  > no need to exchange the key during authentication The public key does need to be exchanged, along with a signature relating it to the current session. This is all handled by TLS, there is no need for the client to send the key in the application data. > You still need to generate it and distribute it to the user This approach avoids distributing secret key material at all. Private keys should ideally never move. They are generated randomly, used to derive the corresponding public key, and then persisted as appropriate. The public key is sent around to other parties.
  - dilyevsky 3y ago
    How do you ensure someone else didn’t just create a new cert with the same user id? At the minimum there needs to be a step to sign the public key (with another flow to prove csr requester identity) Do you see how this a lot more moving pieces than oauth the user needs to figure out? If you’re suggesting to just store a cert thumbprint that means a db call on every request - no different than just a secret token.
- triggercut 3y ago
  I like mTLS, I've worked in scenarios where both mTLS and OAuth are used separately and together, but if the comment here is suggesting certificates will be less complicated than OAuth then I would say I spent an equal amount of time banging my head against the wall with regards to learning and wrangling both, but maybe that's just me, would appreciate anyone else with experience in both to add their take.
willseth 3y ago
Users want to be able to use their existing identity providers. At a minimum it's a red flag for consumers if you don't give them the option to sign in with Google, etc. - and it's simply a deal breaker for many enterprise customers if you can't integrate with their IDP. I wish implementing auth wasn't so complicated now, but the idea that we can just decide to make it so by doing it another way is a fantasy. That ship has sailed.
- dleeftink 3y ago
  My hunch is that this would ring true among some user segments, but would love to see the research on this (both in day-to-day and corporate contexts). From personal experience and those of family members, I'd say we maintain many accounts leftover from bespoke sign-in processes and one-off services. That hasn't turned us from signing-up for these services, in spite of cumbersome onboarding (it's just one of those unfortunate 'hidden costs' of the web). I say this, because we recently went through the trouble of deactivating many of those accounts that were no longer in use. Although the ship may have sailed for alternatives, it will be some time before legacy sign-ons will have been phased out, if at all.
  - marcus_holmes 3y ago
    I'm in the process of finding the things that I used my Google login for and moving them back to "legacy" logins with my email. Part of the process of de-Googling my life.
    - dleeftink 3y ago
      How's your experience been so far? Have you substituted some services completely?
      - marcus_holmes 3y ago
        Gmail is the bugger to get rid of. I need a backup email for my FastMail account, but I don't want to pay for two accounts when I'm only ever going to use the second one as the backup (and the obvious hack of creating a second alias for the FastMail account is equally obviously bound to fail). Drive is still useful sometimes, mostly because my wife is addicted to it, but for a lot of the stuff I was using this for, I now use my Remarkable (and their SaaS). Photos is one of those where I debate the usefulness of any of it. 99% of my photos are shite and not worth saving. The 1% that are, I need to curate a lot more than I do, and the curation is the problem not the storage. Ideally I'd like 2 buttons on the camera, one for "take this photo and delete it in 24 hours" and the other "take this photo and add it to my long-term storage with $this tag" Getting third parties off Google login and on to email/password (using a paid password manager) was pretty simple, though I still find occasional sites that are just "welcome back <gmail address>!" and I have to work out how to get that changed. Haven't had any huge problems with that so far, apart from the usual "change email address, try to login again, get wrong password, reset password, 745395739 captcha attempts, generate password in password manager, save new password, login successful finally" dance.
abhibeckert 3y ago
The main problem with OAuth is it's a three party system. You have an API provider service, an API client service, an a human telling the provider that the client should be allowed to access a limited subset of data on the provider service. That's fine in cases where you actually need three parties involved, e.g. an API that allows access to a user's photo library stored in the cloud... but that's not every situation and if you can avoid it, you should. A simple two party system, where the API provider authorises the API client, is vastly simpler. And just as secure (more secure even, because complexity is the enemy of security).

AlphaSite 3y ago

JWTS (and related token type approaches) are a solution to the whole: how do I avoid spending time doing authn on every request?

dilyevsky 3y ago

If you use mTLS client identity is proven cryptographically (normally via /CN x509 field) - no need to exchange the key during authentication. You still need to generate it and distribute it to the user and manage its lifecycle which gets you to the same place as OAuth except with worse library support

brendoncarroll 3y ago
> no need to exchange the key during authentication The public key does need to be exchanged, along with a signature relating it to the current session. This is all handled by TLS, there is no need for the client to send the key in the application data. > You still need to generate it and distribute it to the user This approach avoids distributing secret key material at all. Private keys should ideally never move. They are generated randomly, used to derive the corresponding public key, and then persisted as appropriate. The public key is sent around to other parties.
- dilyevsky 3y ago
  How do you ensure someone else didn’t just create a new cert with the same user id? At the minimum there needs to be a step to sign the public key (with another flow to prove csr requester identity) Do you see how this a lot more moving pieces than oauth the user needs to figure out? If you’re suggesting to just store a cert thumbprint that means a db call on every request - no different than just a secret token.
triggercut 3y ago
I like mTLS, I've worked in scenarios where both mTLS and OAuth are used separately and together, but if the comment here is suggesting certificates will be less complicated than OAuth then I would say I spent an equal amount of time banging my head against the wall with regards to learning and wrangling both, but maybe that's just me, would appreciate anyone else with experience in both to add their take.

willseth 3y ago

Users want to be able to use their existing identity providers. At a minimum it's a red flag for consumers if you don't give them the option to sign in with Google, etc. - and it's simply a deal breaker for many enterprise customers if you can't integrate with their IDP. I wish implementing auth wasn't so complicated now, but the idea that we can just decide to make it so by doing it another way is a fantasy. That ship has sailed.

dleeftink 3y ago
My hunch is that this would ring true among some user segments, but would love to see the research on this (both in day-to-day and corporate contexts). From personal experience and those of family members, I'd say we maintain many accounts leftover from bespoke sign-in processes and one-off services. That hasn't turned us from signing-up for these services, in spite of cumbersome onboarding (it's just one of those unfortunate 'hidden costs' of the web). I say this, because we recently went through the trouble of deactivating many of those accounts that were no longer in use. Although the ship may have sailed for alternatives, it will be some time before legacy sign-ons will have been phased out, if at all.
- marcus_holmes 3y ago
  I'm in the process of finding the things that I used my Google login for and moving them back to "legacy" logins with my email. Part of the process of de-Googling my life.
  - dleeftink 3y ago
    How's your experience been so far? Have you substituted some services completely?
    - marcus_holmes 3y ago
      Gmail is the bugger to get rid of. I need a backup email for my FastMail account, but I don't want to pay for two accounts when I'm only ever going to use the second one as the backup (and the obvious hack of creating a second alias for the FastMail account is equally obviously bound to fail). Drive is still useful sometimes, mostly because my wife is addicted to it, but for a lot of the stuff I was using this for, I now use my Remarkable (and their SaaS). Photos is one of those where I debate the usefulness of any of it. 99% of my photos are shite and not worth saving. The 1% that are, I need to curate a lot more than I do, and the curation is the problem not the storage. Ideally I'd like 2 buttons on the camera, one for "take this photo and delete it in 24 hours" and the other "take this photo and add it to my long-term storage with $this tag" Getting third parties off Google login and on to email/password (using a paid password manager) was pretty simple, though I still find occasional sites that are just "welcome back <gmail address>!" and I have to work out how to get that changed. Haven't had any huge problems with that so far, apart from the usual "change email address, try to login again, get wrong password, reset password, 745395739 captcha attempts, generate password in password manager, save new password, login successful finally" dance.

abhibeckert 3y ago

The main problem with OAuth is it's a three party system. You have an API provider service, an API client service, an a human telling the provider that the client should be allowed to access a limited subset of data on the provider service. That's fine in cases where you actually need three parties involved, e.g. an API that allows access to a user's photo library stored in the cloud... but that's not every situation and if you can avoid it, you should. A simple two party system, where the API provider authorises the API client, is vastly simpler. And just as secure (more secure even, because complexity is the enemy of security).