8 ms·

OIDC (and the rest of the OAuth umbrella of stuff) is one category where every time I have to work with the protocols I think "there must be a less confusing wa

OIDC (and the rest of the OAuth umbrella of stuff) is one category where every time I have to work with the protocols I think "there must be a less confusing way" and then have a failure of imagination for a simpler way to accomplish the same thing. I think it's because the protocols are conceptually simple, but the cryptographic parts, especially the PKI parts, make them intricate to understand exactly who is attesting or validating exactly what.

shadowbanned4 3y ago
I hand-wrote the largest OIDC deployment in the world, after experimenting with other libraries. It is awful. Do not use OpenID, do not use OIDC.
- Craighead 3y ago
  [dead]
- taeric 3y ago
  Do you have a recommendation on what to use instead?
  - shadowbanned4 3y ago
    HTTP basic auth, TLS with client certs.
    - dboreham 3y ago
      Those things don't do what OIDC does?
      - shadowbanned4 3y ago
        They do them with much less complexity than OIDC.
        krooj 3y ago
        They absolutely do not and also introduce a significant amount of overhead with respect to key/certificate management.
        chucke 3y ago
        And security (basic auth is as good as sending clear text passwords).
        Nextgrid 3y ago
        > sending clear text passwords Which is totally fine to do over HTTPS.
        ustolemyname 3y ago
        Passwords need to be sent both with the request, and to the requestor. I think GP is referring to sending credentials to the service making the request. It is far better to give service XYZ a time-bound and scope limited token to perform a request than a user's username and password.
    - EthanHeilman 3y ago
      Isn't Google moving toward phasing out TLS client certs in chrome/chromium?
      - jeroenhd 3y ago
        Do you have any source for that? I can't find anything online about this, but that would effectively kill browser mTLS.
        EthanHeilman 3y ago
        Chromium removed support for generating TLS Client Certs within chrome in 2016 [0] and ever since then it has gotten harder and harder to use mTLS in Chrome/Chromium. Ten years ago it wasn't a great UX, but now it isn't even obvious how to use it. The impression I've gotten is that Chrome isn't interested mTLS. [0]: https://groups.google.com/a/chromium.org/g/blink-dev/c/z_qEpmzzKh8/m/2hkaJdtsCAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/z_qEp...
  - munchbunny 3y ago
    For complex cases, use SSO providers and service-to-service connectors that hide the underlying protocol from you. If you must manage auth in a more custom way, use things like Azure Active Directory or other competitors. They probably use some OpenID or OIDC under the hood, but the vast majority of software products shouldn’t actually need to implement the protocols directly. For simple cases, plain old TLS should be enough, ideally with short lived client certs. It’s a bit like “don’t roll your own crypto” advice. Don’t roll your own auth.
    - taeric 3y ago
      Ok, this feels like different advice, to me. It isn't to not use these, it is not to be the one implementing them? That is a lot easier to understand. I've been using AWS Cognito to get basic stuff up and running and it hasn't been too bad, I don't think. Have to convince people to not punch holes in things, but so far I have not been too turned off from things.
      - opportune 3y ago
        My recent experience setting up AWS Cognito (not through Amplify) was pretty rough. I think vanilla Cognito doesn’t do a very good job of delivering you something that actually works out of the box with no footguns - you still have to handroll a lot of stuff.
        taeric 3y ago
        On the AuthN side, it seems to be... fine? For AuthZ, things are not surprisingly outsourced heavily to the application side. I'm not clear on how I would want that to be any different, all told. Last thing I, personally, want to deal with is an annotation style setup to control who can do what. I am luckily working with something where we can have pretty easy definitions on who can do what. I would love to hear more of the foot guns, though. Not trying to deny they exist.
        opportune 3y ago
steve1977 3y ago
It’s not because of cryptography, but because of abusing technologies not made for interactive stateful applications (i.e. HTTP, HTML etc.) for interactive stateful applications.
- nine_k 3y ago
  I don't see how the display layer (HTML, CSS) or transport layer (http, TLS) are not suitable for mildly interactive stateful applications. All the state is on the server, except a few cookies. What they are "abusing" is the fact that the same browser, under user's control, may have access to many sites which don't by default trust each other. The user can attest that they should.
- munchbunny 3y ago
  I used to think this, but I’ve also worked on authentication/authorization in contexts where you’re not constrained to HTTP requests, and it doesn’t really get any less complex once federated identities, finer grained access control features, and revocation enter the mix. Sure trying to do everything through JWT’s and cookies makes things harder, but reasoning about attestations by a user from one federated identity provider that a service from a different federated identity provider should be able to query specific data on behalf of the user is messy no matter where you do it, and every medium sized enterprise has that problem somewhere in the IT stack. At that point JWT is just another serialization format for passing attested data around.
opportune 3y ago
What’s insane to me is that it feels like nobody has actually managed to make this easy for developers yet. If they have, I don’t know about them. I would normally consider myself pretty competent, but I stood up my first fully featured website recently with logins and such, and it took me about 2 days of work to get AWS Cognito working (using their recommended USER_SRP_AUTH). That’s not including 3rd party login functionality from Google and friends. Their documentation and UX is piss-poor unless you’re willing to onboard your entire project to Amplify and enter npm-hell, which I wasn’t. It’s almost like they don’t even want your business. I looked into using Auth0 instead and it didn’t seem to be any easier. Better docs, seems like they’re actually written by someone who both understands the auth problem domain and how to explain it to those that don’t, but still complex. Yet when I was finished finally getting everything to work, it seems like the kind of thing you could easily package into an off-the-shelf product. It’s just that existing products don’t do it. Like why the fuck is there a guide explaining how to write a lambda to convert access codes to refresh tokens and persist them via cookies? That should be part of the Cognito platform! Honestly thinking of just starting my own auth SAAS with blackjack and hookers
- grinich 3y ago
  Have you tried WorkOS? (I work there.) Makes it super easy to add SAML/SCIM to your app. https://workos.com/ https://workos.com/ We also recently launched https://www.authkit.com/ https://www.authkit.com/
  - aidos 3y ago
    I had a look at this recently and the pricing was pretty wild. Am I right in understanding that the connection charge is effectively per organisation?
    - grinich 3y ago
      Yes, per organization. SAML/SCIM have no user limits. Hosted AuthKit is free up to 1,000,000 MAUs. https://workos.com/pricing https://workos.com/pricing
  - 3y ago
throwawaaarrgh 3y ago
The crypto isn't complicated. What makes it complicated is the 10,000 different use cases they want the solution to work for, rather than one solution per use case, and a loose coupling interface for all of them.
egnehots 3y ago
No, it can indeed be vastly simpler to handle auth. But you have to consider many complex aspects to provide a simple solution: - What are your real use cases (authentication, authorization, delegation?) - What is your threat model? (avoiding silly mistakes, preventing corporate espionage, defending against targeted attacks require very very different solutions) - How to integrate into your ecosystem (tech stack, actors, layers..) Then you might be able to remove some constraints. You might not need authorization delegation, stateless and readable json tokens. But often it's easier to not think too much about it and just use "an industry proven standard", and that is oauth2 and OIDC: a large auth umbrella to avoid looking at the sun.
jeroenhd 3y ago
If you're writing software to authenticate users, the protocol is huge and complicated. That's why there are full prebuilt containers and SaaS authentication services that solve this problem. There are entire server implementations you can extend, but with tools like Zitadel and Keycloak ready to be configured and deployed for all manner of use cases, I don't see why you would. If you're just authenticating your client app against a server, it's pretty easy (all you need is two tokens and a URL for most librarlies). With some web servers (Apache, Caddy, the paid version of nginx) you can put that config in a location block and have it deal with the entire auth flow, so all your application needs to do is take the REMOTE_USER header or call /whoami to find out who the user is logged in as. Doing auth correctly is just hard. Personally, I treat it like I treat dates/times: use something someone else made, unless you have a particularly weird use case that nobody else supports.

shadowbanned4 3y ago

I hand-wrote the largest OIDC deployment in the world, after experimenting with other libraries. It is awful. Do not use OpenID, do not use OIDC.

Craighead 3y ago
[dead]
taeric 3y ago
Do you have a recommendation on what to use instead?
- shadowbanned4 3y ago
  HTTP basic auth, TLS with client certs.
  - dboreham 3y ago
    Those things don't do what OIDC does?
    - shadowbanned4 3y ago
      They do them with much less complexity than OIDC.
      - krooj 3y ago
        They absolutely do not and also introduce a significant amount of overhead with respect to key/certificate management.
        chucke 3y ago
        And security (basic auth is as good as sending clear text passwords).
        Nextgrid 3y ago
        > sending clear text passwords Which is totally fine to do over HTTPS.
        ustolemyname 3y ago
        Passwords need to be sent both with the request, and to the requestor. I think GP is referring to sending credentials to the service making the request. It is far better to give service XYZ a time-bound and scope limited token to perform a request than a user's username and password.
  - EthanHeilman 3y ago
    Isn't Google moving toward phasing out TLS client certs in chrome/chromium?
    - jeroenhd 3y ago
      Do you have any source for that? I can't find anything online about this, but that would effectively kill browser mTLS.
      - EthanHeilman 3y ago
        Chromium removed support for generating TLS Client Certs within chrome in 2016 [0] and ever since then it has gotten harder and harder to use mTLS in Chrome/Chromium. Ten years ago it wasn't a great UX, but now it isn't even obvious how to use it. The impression I've gotten is that Chrome isn't interested mTLS. [0]: https://groups.google.com/a/chromium.org/g/blink-dev/c/z_qEpmzzKh8/m/2hkaJdtsCAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/z_qEp...
- munchbunny 3y ago
  For complex cases, use SSO providers and service-to-service connectors that hide the underlying protocol from you. If you must manage auth in a more custom way, use things like Azure Active Directory or other competitors. They probably use some OpenID or OIDC under the hood, but the vast majority of software products shouldn’t actually need to implement the protocols directly. For simple cases, plain old TLS should be enough, ideally with short lived client certs. It’s a bit like “don’t roll your own crypto” advice. Don’t roll your own auth.
  - taeric 3y ago
    Ok, this feels like different advice, to me. It isn't to not use these, it is not to be the one implementing them? That is a lot easier to understand. I've been using AWS Cognito to get basic stuff up and running and it hasn't been too bad, I don't think. Have to convince people to not punch holes in things, but so far I have not been too turned off from things.
    - opportune 3y ago
      My recent experience setting up AWS Cognito (not through Amplify) was pretty rough. I think vanilla Cognito doesn’t do a very good job of delivering you something that actually works out of the box with no footguns - you still have to handroll a lot of stuff.
      - taeric 3y ago
        On the AuthN side, it seems to be... fine? For AuthZ, things are not surprisingly outsourced heavily to the application side. I'm not clear on how I would want that to be any different, all told. Last thing I, personally, want to deal with is an annotation style setup to control who can do what. I am luckily working with something where we can have pretty easy definitions on who can do what. I would love to hear more of the foot guns, though. Not trying to deny they exist.
        opportune 3y ago

steve1977 3y ago

It’s not because of cryptography, but because of abusing technologies not made for interactive stateful applications (i.e. HTTP, HTML etc.) for interactive stateful applications.

nine_k 3y ago
I don't see how the display layer (HTML, CSS) or transport layer (http, TLS) are not suitable for mildly interactive stateful applications. All the state is on the server, except a few cookies. What they are "abusing" is the fact that the same browser, under user's control, may have access to many sites which don't by default trust each other. The user can attest that they should.
munchbunny 3y ago
I used to think this, but I’ve also worked on authentication/authorization in contexts where you’re not constrained to HTTP requests, and it doesn’t really get any less complex once federated identities, finer grained access control features, and revocation enter the mix. Sure trying to do everything through JWT’s and cookies makes things harder, but reasoning about attestations by a user from one federated identity provider that a service from a different federated identity provider should be able to query specific data on behalf of the user is messy no matter where you do it, and every medium sized enterprise has that problem somewhere in the IT stack. At that point JWT is just another serialization format for passing attested data around.

opportune 3y ago

What’s insane to me is that it feels like nobody has actually managed to make this easy for developers yet. If they have, I don’t know about them. I would normally consider myself pretty competent, but I stood up my first fully featured website recently with logins and such, and it took me about 2 days of work to get AWS Cognito working (using their recommended USER_SRP_AUTH). That’s not including 3rd party login functionality from Google and friends. Their documentation and UX is piss-poor unless you’re willing to onboard your entire project to Amplify and enter npm-hell, which I wasn’t. It’s almost like they don’t even want your business. I looked into using Auth0 instead and it didn’t seem to be any easier. Better docs, seems like they’re actually written by someone who both understands the auth problem domain and how to explain it to those that don’t, but still complex. Yet when I was finished finally getting everything to work, it seems like the kind of thing you could easily package into an off-the-shelf product. It’s just that existing products don’t do it. Like why the fuck is there a guide explaining how to write a lambda to convert access codes to refresh tokens and persist them via cookies? That should be part of the Cognito platform! Honestly thinking of just starting my own auth SAAS with blackjack and hookers

grinich 3y ago
Have you tried WorkOS? (I work there.) Makes it super easy to add SAML/SCIM to your app. https://workos.com/ https://workos.com/ We also recently launched https://www.authkit.com/ https://www.authkit.com/
- aidos 3y ago
  I had a look at this recently and the pricing was pretty wild. Am I right in understanding that the connection charge is effectively per organisation?
  - grinich 3y ago
    Yes, per organization. SAML/SCIM have no user limits. Hosted AuthKit is free up to 1,000,000 MAUs. https://workos.com/pricing https://workos.com/pricing
- 3y ago

throwawaaarrgh 3y ago

The crypto isn't complicated. What makes it complicated is the 10,000 different use cases they want the solution to work for, rather than one solution per use case, and a loose coupling interface for all of them.

egnehots 3y ago

No, it can indeed be vastly simpler to handle auth. But you have to consider many complex aspects to provide a simple solution: - What are your real use cases (authentication, authorization, delegation?) - What is your threat model? (avoiding silly mistakes, preventing corporate espionage, defending against targeted attacks require very very different solutions) - How to integrate into your ecosystem (tech stack, actors, layers..) Then you might be able to remove some constraints. You might not need authorization delegation, stateless and readable json tokens. But often it's easier to not think too much about it and just use "an industry proven standard", and that is oauth2 and OIDC: a large auth umbrella to avoid looking at the sun.

jeroenhd 3y ago

If you're writing software to authenticate users, the protocol is huge and complicated. That's why there are full prebuilt containers and SaaS authentication services that solve this problem. There are entire server implementations you can extend, but with tools like Zitadel and Keycloak ready to be configured and deployed for all manner of use cases, I don't see why you would. If you're just authenticating your client app against a server, it's pretty easy (all you need is two tokens and a URL for most librarlies). With some web servers (Apache, Caddy, the paid version of nginx) you can put that config in a location block and have it deal with the entire auth flow, so all your application needs to do is take the REMOTE_USER header or call /whoami to find out who the user is logged in as. Doing auth correctly is just hard. Personally, I treat it like I treat dates/times: use something someone else made, unless you have a particularly weird use case that nobody else supports.