6 ms·

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

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