6 ms·

In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol. Actually go to the core RFCs for OAuth,

In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol. Actually go to the core RFCs for OAuth, and you realize that basically everything is implementation-dependent. You somehow register with the provider as a client (out of band and completely implementation-dependent). Then you ask them to log you in by sending a request to an implementation-dependent webpage, with implementation-dependent parameters (which ones are required are--you guessed it--implementation-dependent), telling them to redirect you to your page when you're done. Well, actually, that assumes you're building a website. If you're a desktop application, you'll do something else. If you're on an embedded system that can't open up a webpage, there's another option. And there's yet more flows. Which ones are supported by the provider? You guessed it, it's all implementation-dependent. Oh, and maybe you need to refresh tokens to login the future. When? If? You guessed it, implementation-dependent! It makes writing a generic OAuth client library hard because there's basically no commonality there. Really, it makes me long for Kerberos as a much saner SSO system than OAuth.

majormajor 4y ago
This is my experience. It's hard because it's very complex. As a non-domain-expert it's hard to separate necessary complexity from unnecessary complexity, but it feels like there's a lot of the latter, plus enough gotchas in the former ("oh, you didn't specify an encryption algorithm that we support in your request, and our logs are terribly unhelpful for realizing that") to make it a giant pain.
- gigatexal 4y ago
  Is Webauthn a better standard?
  - lstamour 4y ago
    Not exactly. With webauthn the complexity lies in frontend - you have to explain how and why users should use this and what it is, how to manage enrolments and so on. Touch ID, Windows Hello and Passkeys might simplify this but it is still more complex to explain to less technical customers than, say, Face ID on an iPhone app to remember your login. If you want an easy all-purpose login flow, sign in by clicking a link in email is still an easy fallback. OAuth from multiple providers also has complexity - Auth0 makes it so you have to maintain separate databases for passwords if you want to support login via OAuth and login from password. You have to link accounts to login from multiple providers. Logins are simply hard work no matter how you slice it. Eventually they will be easy but… I’m not holding my breath. :)
  - waboremo 4y ago
    If you were generally comparing standards: yes. Documentation with it is a breeze. If you're talking about a "replace one standard with the next" type of comparison, then no. You can read more about why here https://oauth.net/webauthn/ https://oauth.net/webauthn/
znpy 4y ago
> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol. Because it is, really. OAuth (2.0) is really the backbone for OpenID.
- TallGuyShort 4y ago
  OpenID Connect, specifically, where a lot of people mix those up and start looking at using OAuth for authentication. And if I'm not mistaken, logging out is implementation-dependent in OpenID Connect. There's some pseudo-standards but implementations vary in my experience. And OpenID Connect also has multiple flows for different kinds of applications. There's still a lot of confusion and complexity here.
  - neurostimulant 4y ago
    I'm still salty about how keycloak changed their openid logout behavior, removed the old behavior in the new version when there are still a lot of oidc clients out there that still expect the old behavior. I have two inatances of keycloak using the same version and somehow both have different iodc logout behaviors. I think it's due to one instance was upgraded from older version and inherited the old behavior, but I can't get the other instance to use the old behavior (the flag mentioned in the docs didn't work) unless I downgrade the version first.
    - grepfru_it 4y ago
      Can you elaborate on this a bit? My logout process through keycloak is through a hidden (back channel) url. As long as I hit that client url it will end the session. Applications, I find, have different behaviors. Gitea logs out the session, portainer just clears browser cookies but the session remains active I’m using the same keycloak setup for almost 2 years now, with upgrades
      - neurostimulant 4y ago
        I was referring to this one: https://keycloak.discourse.group/t/keycloak-redirect-uri-logout/17255 https://keycloak.discourse.group/t/keycloak-redirect-uri-log... There is a flag to restore the old behavior but it doesn't work in newer version. Strangely, an older instance of keycloak I run still uses the old behavior even after being upgraded to latest version, so this issue seems to only affect new instance only.
derefr 4y ago
And this is why there's five "log in with X" buttons on every webapp, but no "tell us your IdP and we'll send you there"; let alone any kind of magical "we'll take your email address and check the DNS record of the domain to figure out who your IdP is, and then send you there." Not because the "figuring out who to OAuth with from DNS" part would be hard to design; but because there's no way to "autodiscover" all those implementation-dependent details of how you're supposed to talk to an OAuth IdP. Compare/contrast: SAML. SAML binding a webapp to an arbitrary IdPs just by punching in the IdP's SAML config endpoint URL? Works perfectly.
- pas 4y ago
  OIDC Discovery to the rescue! https://swagger.io/docs/specification/authentication/openid-connect-discovery/ https://swagger.io/docs/specification/authentication/openid-...
  - pl4nty 4y ago
    As much as I love OIDC, it still doesn't handle out-of-band client registration
    - codebje 4y ago
      https://datatracker.ietf.org/doc/rfc7591/ https://datatracker.ietf.org/doc/rfc7591/ The only reason an authorisation server would support dynamic client registration, however, is because it's meant to be pluggable as the back-end for an API integration suite like Kong Enterprise. The solutions that are one big well-known IdP have no reason to want it, so Google Auth, Amazon Cognito, and similar all don't support it. The solutions that are aimed at letting organisations be an IdP do have reason to offer it: it makes being an IdP easier, because you can stand up a client registration service without using vendor-specific interfaces. No-one who operates an IdP wants arbitrary, uncontrolled public client registration. It'll get abused directly, and it'll enable further abuse of the systems the IdP is meant to protect.
- codebje 4y ago
  There's a single URL for OIDC IdPs too. It's not supported in every web app for the same reason SAML isn't: it's a two-way exchange to set up, not a one-way exchange. In OIDC (OAuth 2) you need to register a client first. In SAML you need to register a Service Provider first. Only after you've done those steps will you be able to plug the magic configuration in and have it work. SAML is too limited to compete with OIDC/OAuth2 on the web, but it's got some advantages for enterprise authentication, so it won't be going anywhere.
Aeolun 4y ago
I think the problem with the spec is that it’s way too large to fully implement when you only need some secure token exchange, so everyone does only the stuff they need. If the spec was smaller people would go all the way to be fully compliant since the marginal effort would be minimal.
yacine_ 4y ago
OAuth isn't an SSO system :P
skissane 4y ago
> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol OAuth supports lots of different scenarios. Many people when they say “OAuth” they are only thinking of one or two of those scenarios, and ignoring all the others which aren’t relevant to them personally-but may be relevant to someone else I worked on a system where we had a micro-service which had a token from OAuth server 1, and it needed to exchange it for a token from OAuth server 2, and we needed some policies to decide whether that token exchange was allowed or not. And that’s totally a use case the OAuth RFCs support (there is even an RFC specifically on token exchange), but a person wanting to add a “login with Google” button to their website isn’t interested in anything remotely like that. > Which ones are supported by the provider? You guessed it, it's all implementation-dependent. Security needs vary widely from system to system. So they defined a protocol which supports many different scenarios. But if your application only needs two of them, why implement the other N? OTOH, for someone who actually needs one of those other scenarios, having it standardised makes their life easier. You can’t expect the protocol to tell you which scenario you have, that’s inherently “implementation-dependent”, to the point that calling it that is getting tautologous
- LukeShu 4y ago
  > > In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol > OAuth supports lots of different scenarios. But it's literally only the skeleton of a protocol ("framework" of a protocol, as the actual spec puts it). That important "Then later on you can take the token and say 'Hey google, somebody gave me this token, who is it?'" part is totally unspecified by OAuth. How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed): - OAuth: implementation defined - most implementations: use our library, which validates the token using undocumented logic - OIDC: there's a user-info endpoint you can call to, but lots of OAuth authorization servers don't fully implement OIDC, and even if they do, that's a lot of extra round trips - RFC7523: The token is a JWT, validate the signature and claims... but everyone issues RFC6750 "bearer" tokens, not RFC7523 "urn:ietf:params:oauth:grant-type:jwt-bearer" tokens. But if you just close your eyes and pretend that your 6750 opaque token is actually a 7523 JWT and parse+validate it as such, that'll work most of the time. So yeah, OAuth is hard because there's no great generic library, because a core part of it is implementation-defined, so you have to either do it yourself or use a specific implementation's library, and none of those libraries work quite the same. (In the above, and for 99% of folks, "OAuth" = RFC6749+RFC6750)
mattpallissard 4y ago
> Kerberos as a much saner SSO system than OAuth. +1, it really solves nearly all the authn and federation problems. You still find KDC installations in places with large *nix footprints. Sometimes it's AD, sometimes it's MIT with a cross-realm trust. It's incredibly flexible and transparent to the user. It's easy for sysadmins, and various service owners to implement as it's basically drop a keytab in place, and set an environment variable for many daemons and libraries. IMO, the only reason it fell out of favor with the web crowd is there wasn't a gaggle of centralized providers that let them stand up services without thinking about the infrastructure. It wasn't packaged up nicely.
- codebje 4y ago
  Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client. OAuth was invented to avoid the need to do that. If I use some finance package and I'd like it to download my transactions from my bank, I'd really rather not have to give it my username and password, with the full access that grants including the ability to lock me out of my bank account and transfer my money. OAuth lets you instead grant permissions for that program to do something more limited, like just read your transaction history. Kerberos was never popular with the web crowd because it's not capable of solving the problem of authorizing web applications. Before OAuth everywhere just asked for your username and password to log in on your behalf. And the only reason Kerberos works well today is that it's always now a single-vendor solution, homogeneous across the deployment. It's an interoperability nightmare otherwise.
  - jcranmer 4y ago
    > Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client. Not really. In practice, Kerberos means just loading the gssapi or sspi library, essentially using the user's login to already have the ticket-granting-ticket generated and usable for the subsequent tickets. As the client application, I never see the user's password; it's all handled for me by the OS.
    - 4y ago
codebje 4y ago
Dynamic client registration is standardised (https://www.rfc-editor.org/rfc/rfc7591.html https://www.rfc-editor.org/rfc/rfc7591.html), the authorization code flow is standardised (https://www.rfc-editor.org/rfc/rfc6749.html https://www.rfc-editor.org/rfc/rfc6749.html). The device authorization flow is also standardised (https://www.rfc-editor.org/rfc/rfc8628.html https://www.rfc-editor.org/rfc/rfc8628.html). The preferred desktop app authorization process is described in a best current practice document (https://www.rfc-editor.org/rfc/rfc8252.html https://www.rfc-editor.org/rfc/rfc8252.html). A metadata URL for auto-configuration of OAuth2 Authorization Servers is specified (https://www.rfc-editor.org/rfc/rfc8414.html https://www.rfc-editor.org/rfc/rfc8414.html). How to validate an access token, which also lets you know if you need to refresh it, is specified (https://www.rfc-editor.org/rfc/rfc7662.html https://www.rfc-editor.org/rfc/rfc7662.html via an API endpoint, https://www.rfc-editor.org/rfc/rfc9068.html https://www.rfc-editor.org/rfc/rfc9068.html for JWT tokens) - or just use it, and if it fails, refresh it. It's fully specified. It's well implemented - you'd have to go out of your way to find an authorization server that doesn't do everything above, with the exception of dynamic client registration, because that's not intended for clients but rather for integration with developer portals and similar. Google Auth and Amazon Cognito don't support dynamic registration for third parties, eg, because if you're doing dynamic registration it'll be because you're operating your own AS - Okta, Auth0, and Keycloak all support it. There's also plenty of good generic OAuth client libraries. Spring Security, the oauth2 crate for Rust, etc.
- smackeyacky 4y ago
  Just because the standards exist doesn't mean everybody follows them. Most and maybe all implementations have some crazy customisation. It makes the standards and docs almost worthless.
  - jeroenhd 4y ago
    But that's hardly OAuth's fault. I can blame HTTP/2 cleartext because none of the websites I'm trying to access are working in my browser, but it's not reasonable to blame a generic protocol for not providing my niche when it's the implementations that are broken. Imagine complaining to the WHATWG because Microsoft decided to host an IRC server on port 80 and none of my browsers work. In my experience, OAuth works great. Standard libraries Just Work, login Just Works, all you need is a URL (usually standardised) and maybe the configuration the service is expecting (i.e. the names of the permissions you're asking the user for). Usually, that's nothing special to set up. In some cases, particularly with huge "fuck you we're big enough to be the standard" vendors, there are some stupid hardcoded values and workarounds you need to deal with because they couldn't be bothered to use a library or document their flawed implementation. I've set up a Keycloak server and authentication against it is super easy to set up. Copy-paste a domain, two generated tokens, and maybe a URL if .well-known discovery isn't implemented by the client, and that's it. Things can be easy, companies providing "OAuth" support just choose to make your life hard.
the8472 4y ago
For a desktop application could use the password flow[0], no need to involve a web browser. Yeah, sure, you're now handing keys to the kingdom to that application, but if it's native software it could also have installed a keylogger or used an embedded browser component and extracted the data from there. [0] https://www.rfc-editor.org/rfc/rfc6749#section-4.3 https://www.rfc-editor.org/rfc/rfc6749#section-4.3

majormajor 4y ago

This is my experience. It's hard because it's very complex. As a non-domain-expert it's hard to separate necessary complexity from unnecessary complexity, but it feels like there's a lot of the latter, plus enough gotchas in the former ("oh, you didn't specify an encryption algorithm that we support in your request, and our logs are terribly unhelpful for realizing that") to make it a giant pain.

gigatexal 4y ago
Is Webauthn a better standard?
- lstamour 4y ago
  Not exactly. With webauthn the complexity lies in frontend - you have to explain how and why users should use this and what it is, how to manage enrolments and so on. Touch ID, Windows Hello and Passkeys might simplify this but it is still more complex to explain to less technical customers than, say, Face ID on an iPhone app to remember your login. If you want an easy all-purpose login flow, sign in by clicking a link in email is still an easy fallback. OAuth from multiple providers also has complexity - Auth0 makes it so you have to maintain separate databases for passwords if you want to support login via OAuth and login from password. You have to link accounts to login from multiple providers. Logins are simply hard work no matter how you slice it. Eventually they will be easy but… I’m not holding my breath. :)
- waboremo 4y ago
  If you were generally comparing standards: yes. Documentation with it is a breeze. If you're talking about a "replace one standard with the next" type of comparison, then no. You can read more about why here https://oauth.net/webauthn/ https://oauth.net/webauthn/

znpy 4y ago

> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol. Because it is, really. OAuth (2.0) is really the backbone for OpenID.

TallGuyShort 4y ago
OpenID Connect, specifically, where a lot of people mix those up and start looking at using OAuth for authentication. And if I'm not mistaken, logging out is implementation-dependent in OpenID Connect. There's some pseudo-standards but implementations vary in my experience. And OpenID Connect also has multiple flows for different kinds of applications. There's still a lot of confusion and complexity here.
- neurostimulant 4y ago
  I'm still salty about how keycloak changed their openid logout behavior, removed the old behavior in the new version when there are still a lot of oidc clients out there that still expect the old behavior. I have two inatances of keycloak using the same version and somehow both have different iodc logout behaviors. I think it's due to one instance was upgraded from older version and inherited the old behavior, but I can't get the other instance to use the old behavior (the flag mentioned in the docs didn't work) unless I downgrade the version first.
  - grepfru_it 4y ago
    Can you elaborate on this a bit? My logout process through keycloak is through a hidden (back channel) url. As long as I hit that client url it will end the session. Applications, I find, have different behaviors. Gitea logs out the session, portainer just clears browser cookies but the session remains active I’m using the same keycloak setup for almost 2 years now, with upgrades
    - neurostimulant 4y ago
      I was referring to this one: https://keycloak.discourse.group/t/keycloak-redirect-uri-logout/17255 https://keycloak.discourse.group/t/keycloak-redirect-uri-log... There is a flag to restore the old behavior but it doesn't work in newer version. Strangely, an older instance of keycloak I run still uses the old behavior even after being upgraded to latest version, so this issue seems to only affect new instance only.

derefr 4y ago

And this is why there's five "log in with X" buttons on every webapp, but no "tell us your IdP and we'll send you there"; let alone any kind of magical "we'll take your email address and check the DNS record of the domain to figure out who your IdP is, and then send you there." Not because the "figuring out who to OAuth with from DNS" part would be hard to design; but because there's no way to "autodiscover" all those implementation-dependent details of how you're supposed to talk to an OAuth IdP. Compare/contrast: SAML. SAML binding a webapp to an arbitrary IdPs just by punching in the IdP's SAML config endpoint URL? Works perfectly.

pas 4y ago
OIDC Discovery to the rescue! https://swagger.io/docs/specification/authentication/openid-connect-discovery/ https://swagger.io/docs/specification/authentication/openid-...
- pl4nty 4y ago
  As much as I love OIDC, it still doesn't handle out-of-band client registration
  - codebje 4y ago
    https://datatracker.ietf.org/doc/rfc7591/ https://datatracker.ietf.org/doc/rfc7591/ The only reason an authorisation server would support dynamic client registration, however, is because it's meant to be pluggable as the back-end for an API integration suite like Kong Enterprise. The solutions that are one big well-known IdP have no reason to want it, so Google Auth, Amazon Cognito, and similar all don't support it. The solutions that are aimed at letting organisations be an IdP do have reason to offer it: it makes being an IdP easier, because you can stand up a client registration service without using vendor-specific interfaces. No-one who operates an IdP wants arbitrary, uncontrolled public client registration. It'll get abused directly, and it'll enable further abuse of the systems the IdP is meant to protect.
codebje 4y ago
There's a single URL for OIDC IdPs too. It's not supported in every web app for the same reason SAML isn't: it's a two-way exchange to set up, not a one-way exchange. In OIDC (OAuth 2) you need to register a client first. In SAML you need to register a Service Provider first. Only after you've done those steps will you be able to plug the magic configuration in and have it work. SAML is too limited to compete with OIDC/OAuth2 on the web, but it's got some advantages for enterprise authentication, so it won't be going anywhere.

Aeolun 4y ago

I think the problem with the spec is that it’s way too large to fully implement when you only need some secure token exchange, so everyone does only the stuff they need. If the spec was smaller people would go all the way to be fully compliant since the marginal effort would be minimal.

yacine_ 4y ago

OAuth isn't an SSO system :P

skissane 4y ago

> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol OAuth supports lots of different scenarios. Many people when they say “OAuth” they are only thinking of one or two of those scenarios, and ignoring all the others which aren’t relevant to them personally-but may be relevant to someone else I worked on a system where we had a micro-service which had a token from OAuth server 1, and it needed to exchange it for a token from OAuth server 2, and we needed some policies to decide whether that token exchange was allowed or not. And that’s totally a use case the OAuth RFCs support (there is even an RFC specifically on token exchange), but a person wanting to add a “login with Google” button to their website isn’t interested in anything remotely like that. > Which ones are supported by the provider? You guessed it, it's all implementation-dependent. Security needs vary widely from system to system. So they defined a protocol which supports many different scenarios. But if your application only needs two of them, why implement the other N? OTOH, for someone who actually needs one of those other scenarios, having it standardised makes their life easier. You can’t expect the protocol to tell you which scenario you have, that’s inherently “implementation-dependent”, to the point that calling it that is getting tautologous

LukeShu 4y ago
> > In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol > OAuth supports lots of different scenarios. But it's literally only the skeleton of a protocol ("framework" of a protocol, as the actual spec puts it). That important "Then later on you can take the token and say 'Hey google, somebody gave me this token, who is it?'" part is totally unspecified by OAuth. How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed): - OAuth: implementation defined - most implementations: use our library, which validates the token using undocumented logic - OIDC: there's a user-info endpoint you can call to, but lots of OAuth authorization servers don't fully implement OIDC, and even if they do, that's a lot of extra round trips - RFC7523: The token is a JWT, validate the signature and claims... but everyone issues RFC6750 "bearer" tokens, not RFC7523 "urn:ietf:params:oauth:grant-type:jwt-bearer" tokens. But if you just close your eyes and pretend that your 6750 opaque token is actually a 7523 JWT and parse+validate it as such, that'll work most of the time. So yeah, OAuth is hard because there's no great generic library, because a core part of it is implementation-defined, so you have to either do it yourself or use a specific implementation's library, and none of those libraries work quite the same. (In the above, and for 99% of folks, "OAuth" = RFC6749+RFC6750)

mattpallissard 4y ago

> Kerberos as a much saner SSO system than OAuth. +1, it really solves nearly all the authn and federation problems. You still find KDC installations in places with large *nix footprints. Sometimes it's AD, sometimes it's MIT with a cross-realm trust. It's incredibly flexible and transparent to the user. It's easy for sysadmins, and various service owners to implement as it's basically drop a keytab in place, and set an environment variable for many daemons and libraries. IMO, the only reason it fell out of favor with the web crowd is there wasn't a gaggle of centralized providers that let them stand up services without thinking about the infrastructure. It wasn't packaged up nicely.

codebje 4y ago
Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client. OAuth was invented to avoid the need to do that. If I use some finance package and I'd like it to download my transactions from my bank, I'd really rather not have to give it my username and password, with the full access that grants including the ability to lock me out of my bank account and transfer my money. OAuth lets you instead grant permissions for that program to do something more limited, like just read your transaction history. Kerberos was never popular with the web crowd because it's not capable of solving the problem of authorizing web applications. Before OAuth everywhere just asked for your username and password to log in on your behalf. And the only reason Kerberos works well today is that it's always now a single-vendor solution, homogeneous across the deployment. It's an interoperability nightmare otherwise.
- jcranmer 4y ago
  > Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client. Not really. In practice, Kerberos means just loading the gssapi or sspi library, essentially using the user's login to already have the ticket-granting-ticket generated and usable for the subsequent tickets. As the client application, I never see the user's password; it's all handled for me by the OS.
  - 4y ago

codebje 4y ago

Dynamic client registration is standardised (https://www.rfc-editor.org/rfc/rfc7591.html https://www.rfc-editor.org/rfc/rfc7591.html), the authorization code flow is standardised (https://www.rfc-editor.org/rfc/rfc6749.html https://www.rfc-editor.org/rfc/rfc6749.html). The device authorization flow is also standardised (https://www.rfc-editor.org/rfc/rfc8628.html https://www.rfc-editor.org/rfc/rfc8628.html). The preferred desktop app authorization process is described in a best current practice document (https://www.rfc-editor.org/rfc/rfc8252.html https://www.rfc-editor.org/rfc/rfc8252.html). A metadata URL for auto-configuration of OAuth2 Authorization Servers is specified (https://www.rfc-editor.org/rfc/rfc8414.html https://www.rfc-editor.org/rfc/rfc8414.html). How to validate an access token, which also lets you know if you need to refresh it, is specified (https://www.rfc-editor.org/rfc/rfc7662.html https://www.rfc-editor.org/rfc/rfc7662.html via an API endpoint, https://www.rfc-editor.org/rfc/rfc9068.html https://www.rfc-editor.org/rfc/rfc9068.html for JWT tokens) - or just use it, and if it fails, refresh it. It's fully specified. It's well implemented - you'd have to go out of your way to find an authorization server that doesn't do everything above, with the exception of dynamic client registration, because that's not intended for clients but rather for integration with developer portals and similar. Google Auth and Amazon Cognito don't support dynamic registration for third parties, eg, because if you're doing dynamic registration it'll be because you're operating your own AS - Okta, Auth0, and Keycloak all support it. There's also plenty of good generic OAuth client libraries. Spring Security, the oauth2 crate for Rust, etc.

smackeyacky 4y ago
Just because the standards exist doesn't mean everybody follows them. Most and maybe all implementations have some crazy customisation. It makes the standards and docs almost worthless.
- jeroenhd 4y ago
  But that's hardly OAuth's fault. I can blame HTTP/2 cleartext because none of the websites I'm trying to access are working in my browser, but it's not reasonable to blame a generic protocol for not providing my niche when it's the implementations that are broken. Imagine complaining to the WHATWG because Microsoft decided to host an IRC server on port 80 and none of my browsers work. In my experience, OAuth works great. Standard libraries Just Work, login Just Works, all you need is a URL (usually standardised) and maybe the configuration the service is expecting (i.e. the names of the permissions you're asking the user for). Usually, that's nothing special to set up. In some cases, particularly with huge "fuck you we're big enough to be the standard" vendors, there are some stupid hardcoded values and workarounds you need to deal with because they couldn't be bothered to use a library or document their flawed implementation. I've set up a Keycloak server and authentication against it is super easy to set up. Copy-paste a domain, two generated tokens, and maybe a URL if .well-known discovery isn't implemented by the client, and that's it. Things can be easy, companies providing "OAuth" support just choose to make your life hard.

the8472 4y ago

For a desktop application could use the password flow[0], no need to involve a web browser. Yeah, sure, you're now handing keys to the kingdom to that application, but if it's native software it could also have installed a keylogger or used an embedded browser component and extracted the data from there. [0] https://www.rfc-editor.org/rfc/rfc6749#section-4.3 https://www.rfc-editor.org/rfc/rfc6749#section-4.3