5 ms·

Cool project! OAuth-based auth providers are nice, but they can have a weakness. When you have just one app, OAuth can be overkill: protocol is complex, and us

by ash 2y ago

Cool project! OAuth-based auth providers are nice, but they can have a weakness. When you have just one app, OAuth can be overkill: protocol is complex, and users suffer jarring redirects¹. This is not surprising, because OAuth / OIDC is fundamentally designed for (at least) three parties that don't fully trust each other: user, account provider and an app². But in a single app there are only two parties: user and app itself. Auth and app can fully trust each other, protocol can be simpler, and redirects can be avoided. I'm curious what OpenAUTH authors think about it. ¹ Except for Resource Owner Password Credentials (ROPC) grant type, but it's no longer recommended: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.4 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur... ² In addition, OAuth is mostly designed for and by account providers, and follows their interests more than interests of app developers.

lstamour 2y ago
It's fair to say that with OAuth the resource owner can choose to display a consent screen or not. For example, when consent is granted already, it can be skipped if the resource owner does not need it. Likewise, Google Workspace and other enterprise services that use OAuth can configure in advance which apps are trusted and thus skip permission grants. Not to say the concern about redirects isn't legitimate, but there are other ways of handling this. Even redirects aren't necessary if OAuth is implemented in a browser-less or embedded browser fashion, e.g. SFAuthenticationSession for one non-standard example. I haven't looked this up in awhile but I believe the OAuth protocol was being extended more and more to other contexts beyond the browser - e.g. code flow or new app-based flows and even QR auth flows for TV or sharing prompts. (Note I am not commenting on OpenAUTH, just OAuth in general. It's complex, yes, but not as bad as it might seem at first glance. It's just not implemented in a standard way across every provider. Something like PassKeys might one day replace it.)
- portaouflop 2y ago
  > Even redirects aren't necessary if OAuth is implemented in a browser-less or embedded browser fashion, e.g. SFAuthenticationSession Can you please expand on that or give me some hints what to look at? I have never heard of this before and I work with Oauth2 a lot. When I look for SFAuthenticationSession it seems to be specific to Safari and also deprecated. I always share this article because people overimplement OAuth2 for everything, it’s not a hammer: https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/ https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cas...
  - lstamour 2y ago
    For browserless, I was referring to a 2019 article that I could have sworn was newer than that, on the need for OAuth 2.1 that also covers how they added OAuth for Native Apps (Code Flow) and basically a QR code version for TVs: https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1 https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-... As for SFAuthenticationSession, again my info might be outdated, but the basic idea is that there are often native APIs that can load OAuth requests in a way that doesn’t require you to relogin. Honestly most of those use cases have been deprecated by PassKeys at an operating system level. There’s (almost) no need for a special browser with cookies to your favourite authenticated services if you have PassKeys to make logging in more painless.
    - portaouflop 2y ago
      Thanks for sharing! I agree that passkeys would solve all that, but they have their own set of problems (mainly being bound to a device) and they are still very far from being universally adopted. I’m looking forward to OAuth2.1 - at the moment it is still in draft stage, so it will take a couple more years until it’s done and providers start implementing. My prediction is that passwords will be around for a long time, at least the next 10 years.
      - lstamour 2y ago
        PassKeys are definitely the future, they aren't just device-specific, they can be synced also. https://www.corbado.com/blog/nist-passkeys https://www.corbado.com/blog/nist-passkeys talks about this, though I'll admit I haven't read anything on the subject yet. But I can say that most implementations of PassKeys seem to cloud sync, including 1Password, Apple, Google, Edge, etc. I should also add that PassKeys that are tied to devices are like FIDO2 security keys, you should be able to add more than one to your account so that you can login with a backup if your primary FIDO2 token is unavailable. Likewise, SSO should ideally be implemented such that you can link more than one social network - and a standard email address or backup method - in addition to the primary method you might use to login with. It has always bugged me that Auth0 makes it much harder than it should be to link multiple methods of login to an account, by default.
afiori 2y ago
My personal gripe with OAuth is that the simple case can be implemented with like 2 redirects and 2 curls, but docs are often incomprehensibly complicated by dozens of layers of abstractions, services, extensions, enterprise account management and such.

by ash 2y ago

lstamour 2y ago

It's fair to say that with OAuth the resource owner can choose to display a consent screen or not. For example, when consent is granted already, it can be skipped if the resource owner does not need it. Likewise, Google Workspace and other enterprise services that use OAuth can configure in advance which apps are trusted and thus skip permission grants. Not to say the concern about redirects isn't legitimate, but there are other ways of handling this. Even redirects aren't necessary if OAuth is implemented in a browser-less or embedded browser fashion, e.g. SFAuthenticationSession for one non-standard example. I haven't looked this up in awhile but I believe the OAuth protocol was being extended more and more to other contexts beyond the browser - e.g. code flow or new app-based flows and even QR auth flows for TV or sharing prompts. (Note I am not commenting on OpenAUTH, just OAuth in general. It's complex, yes, but not as bad as it might seem at first glance. It's just not implemented in a standard way across every provider. Something like PassKeys might one day replace it.)

portaouflop 2y ago
> Even redirects aren't necessary if OAuth is implemented in a browser-less or embedded browser fashion, e.g. SFAuthenticationSession Can you please expand on that or give me some hints what to look at? I have never heard of this before and I work with Oauth2 a lot. When I look for SFAuthenticationSession it seems to be specific to Safari and also deprecated. I always share this article because people overimplement OAuth2 for everything, it’s not a hammer: https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/ https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cas...
- lstamour 2y ago
  For browserless, I was referring to a 2019 article that I could have sworn was newer than that, on the need for OAuth 2.1 that also covers how they added OAuth for Native Apps (Code Flow) and basically a QR code version for TVs: https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1 https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-... As for SFAuthenticationSession, again my info might be outdated, but the basic idea is that there are often native APIs that can load OAuth requests in a way that doesn’t require you to relogin. Honestly most of those use cases have been deprecated by PassKeys at an operating system level. There’s (almost) no need for a special browser with cookies to your favourite authenticated services if you have PassKeys to make logging in more painless.
  - portaouflop 2y ago
    Thanks for sharing! I agree that passkeys would solve all that, but they have their own set of problems (mainly being bound to a device) and they are still very far from being universally adopted. I’m looking forward to OAuth2.1 - at the moment it is still in draft stage, so it will take a couple more years until it’s done and providers start implementing. My prediction is that passwords will be around for a long time, at least the next 10 years.
    - lstamour 2y ago
      PassKeys are definitely the future, they aren't just device-specific, they can be synced also. https://www.corbado.com/blog/nist-passkeys https://www.corbado.com/blog/nist-passkeys talks about this, though I'll admit I haven't read anything on the subject yet. But I can say that most implementations of PassKeys seem to cloud sync, including 1Password, Apple, Google, Edge, etc. I should also add that PassKeys that are tied to devices are like FIDO2 security keys, you should be able to add more than one to your account so that you can login with a backup if your primary FIDO2 token is unavailable. Likewise, SSO should ideally be implemented such that you can link more than one social network - and a standard email address or backup method - in addition to the primary method you might use to login with. It has always bugged me that Auth0 makes it much harder than it should be to link multiple methods of login to an account, by default.

afiori 2y ago

My personal gripe with OAuth is that the simple case can be implemented with like 2 redirects and 2 curls, but docs are often incomprehensibly complicated by dozens of layers of abstractions, services, extensions, enterprise account management and such.