4 ms·

When we let "the industry" set our standards, we get a mess of crap that works for the specific use cases of the giant companies that created it. Meanwhile, act

When we let "the industry" set our standards, we get a mess of crap that works for the specific use cases of the giant companies that created it. Meanwhile, actually using these things ourselves leaves out a lot of use cases, adds complexity, and becomes burdensome, to the point you don't even want to use it. We need the international software development community to have its own standards body outside of massive corporations and creaking old institutions with outsized influence. Standards should represent the majority of people writing and using the code.

anderspitman 3y ago
I do think it's pretty amazing that a basic modern authorization system essential has a hard dependency on a 20+ million lines of code web browser, even for native apps. And mostly just because we need a central location to store auth cookies. I'd love to see a stripped-down "auth browser" that has no job other than rendering basic style-free forms (maybe even declared in JSON) and storing cookies. Problem is you have to get the big boys to stop requiring JavaScript for their auth flows. That said, after doing a decent amount of implementing OAuth2/OpenID Connect, the core profiles are actually pretty reasonable and about what you would want to do if you were starting from scratch. The trick is making sense of all the optional stuff. There have been some efforts[0] to improve that. The part I've never been able to figure out is why does OAuth2 use tokens at all, rather than generating a key pair and sending the public key with the initial auth request, then signing subsequent requests? [0]: https://fusionauth.io/articles/oauth/differences-between-oauth-2-oauth-2-1 https://fusionauth.io/articles/oauth/differences-between-oau...
- Solvency 3y ago
  What's the super Birds Eye view tldr reason that such a thing does require 20 million lines of code? How did this happen?
  - flashback2199 3y ago
    I don't think OIDC requires a browser.
    - anderspitman 3y ago
      I would be very interested to see an implementation that doesn't. And I'm not being sarcastic. Even the device flow has you open a browser on another device.
      - pugz 3y ago
        I guess it depends on what we meant when we talk about OIDC, but in system-to-system authentication (e.g. GitHub Actions to ${cloud provider}), there are no browsers involved. But that's a fairly different use-case that happens to be under the OIDC umbrella. https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect https://docs.github.com/en/actions/deployment/security-harde...
      - fireflash38 3y ago
        Basically just resource owner/password flow. Because clearly programmers don't know how to handle sensitive information, only browsers can.
  - anderspitman 3y ago
    I think it mostly just evolved that way. OAuth started on the web and if you're using a browser anyway you might as well take advantage of HTML/JS rendering for the UI and cookies for secure storage.
    - alexvoda 3y ago
      https://player.vimeo.com/video/52882780 https://player.vimeo.com/video/52882780
  - EGreg 3y ago
    Well I saw this the other day https://m.youtube.com/watch?v=kZRE7HIO3vk https://m.youtube.com/watch?v=kZRE7HIO3vk
  - LastTrain 3y ago
    Because everyone already has it installed.
carstenhag 3y ago
But who pays those? Only big companies have the will power and money to pay someone to only write standards.
- OJFord 3y ago
  We should be members of a professional institution. In any other profession, it would set such standards, or at least somewhat govern the academic contribution to them. I am a member of the IET, but it's not strong on CS/SE. Some might be of the BCS (aka Chartered Institute for IT, which says it all IMO) or ACM. The latter is probably the most relevant we have, but it's more publication focussed than professional development/regulation/whistleblowing support/standards providing etc. of traditional bodies.
- deleted 3y ago
  [deleted]
- throwaway892238 3y ago
  they could be written by the community, without money. most of the internet runs on software not created by a big company
  - AceJohnny2 3y ago
    > most of the internet runs on software not created by a big company I think you underestimate the amount of sponsorship that carries open-source developers. For example, have a look at the "Most active 6.3 employers" section for contributions to the 6.3 kernel, which amount to over 75% of the lines changed. https://lwn.net/Articles/929582/ https://lwn.net/Articles/929582/
    - throwaway892238 3y ago
      That is one open source project. There are millions.
api 3y ago
You forgot lock in. OIDC is an absolute nightmare for this. Watching everyone delegate all access control to Google and Microsoft is… I don’t even know what to say. It’s such an obvious trap but it’s convenient and convenience is the only thing anyone cares about. I’m gonna say I told you so in a few years. Nobody will care.
- pphysch 3y ago
  What "lock in"? If I use Google OIDC for my app, there's nothing stopping me from automatically migrating every Google user to a local account pre-populated with their Google claims, or from mapping those users to different identities, and permanently disabling Google OIDC.
  - api 3y ago
    I’m talking about users. Can users change their login provider? Some apps allow this but most don’t.
    - clintonb 3y ago
      > Can users change their login provider? Some apps allow this but most don’t. You answered your own question. This is an issue with the app creator not supporting multiple providers, not with OIDC.
  - donmcronald 3y ago
    I've never used it, but they can ban your app token, right? So I assume you need to make sure you're keeping your own up-to-date copy of all claims you have access to. > there's nothing stopping me from automatically migrating every Google user to a local account pre-populated with their Google claims I wonder your user retention would look like in that situation.
    - dikei 3y ago
      > I've never used it, but they can ban your app token, right? So I assume you need to make sure you're keeping your own up-to-date copy of all claims you have access to. That's why you should always provide multiple method of authentication. A simple way is fetching your user email from the OIDC provider, then use it for username/password authn. It's less convenient, but it prevents user from being locked out in case something's wrong with OIDC.
CrazyPyroLinux 3y ago
That comment reminded me so much of https://xkcd.com/927/ https://xkcd.com/927/

anderspitman 3y ago

I do think it's pretty amazing that a basic modern authorization system essential has a hard dependency on a 20+ million lines of code web browser, even for native apps. And mostly just because we need a central location to store auth cookies. I'd love to see a stripped-down "auth browser" that has no job other than rendering basic style-free forms (maybe even declared in JSON) and storing cookies. Problem is you have to get the big boys to stop requiring JavaScript for their auth flows. That said, after doing a decent amount of implementing OAuth2/OpenID Connect, the core profiles are actually pretty reasonable and about what you would want to do if you were starting from scratch. The trick is making sense of all the optional stuff. There have been some efforts[0] to improve that. The part I've never been able to figure out is why does OAuth2 use tokens at all, rather than generating a key pair and sending the public key with the initial auth request, then signing subsequent requests? [0]: https://fusionauth.io/articles/oauth/differences-between-oauth-2-oauth-2-1 https://fusionauth.io/articles/oauth/differences-between-oau...

Solvency 3y ago
What's the super Birds Eye view tldr reason that such a thing does require 20 million lines of code? How did this happen?
- flashback2199 3y ago
  I don't think OIDC requires a browser.
  - anderspitman 3y ago
    I would be very interested to see an implementation that doesn't. And I'm not being sarcastic. Even the device flow has you open a browser on another device.
    - pugz 3y ago
      I guess it depends on what we meant when we talk about OIDC, but in system-to-system authentication (e.g. GitHub Actions to ${cloud provider}), there are no browsers involved. But that's a fairly different use-case that happens to be under the OIDC umbrella. https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect https://docs.github.com/en/actions/deployment/security-harde...
    - fireflash38 3y ago
      Basically just resource owner/password flow. Because clearly programmers don't know how to handle sensitive information, only browsers can.
- anderspitman 3y ago
  I think it mostly just evolved that way. OAuth started on the web and if you're using a browser anyway you might as well take advantage of HTML/JS rendering for the UI and cookies for secure storage.
  - alexvoda 3y ago
    https://player.vimeo.com/video/52882780 https://player.vimeo.com/video/52882780
- EGreg 3y ago
  Well I saw this the other day https://m.youtube.com/watch?v=kZRE7HIO3vk https://m.youtube.com/watch?v=kZRE7HIO3vk
- LastTrain 3y ago
  Because everyone already has it installed.

carstenhag 3y ago

But who pays those? Only big companies have the will power and money to pay someone to only write standards.

OJFord 3y ago
We should be members of a professional institution. In any other profession, it would set such standards, or at least somewhat govern the academic contribution to them. I am a member of the IET, but it's not strong on CS/SE. Some might be of the BCS (aka Chartered Institute for IT, which says it all IMO) or ACM. The latter is probably the most relevant we have, but it's more publication focussed than professional development/regulation/whistleblowing support/standards providing etc. of traditional bodies.
deleted 3y ago
[deleted]
throwaway892238 3y ago
they could be written by the community, without money. most of the internet runs on software not created by a big company
- AceJohnny2 3y ago
  > most of the internet runs on software not created by a big company I think you underestimate the amount of sponsorship that carries open-source developers. For example, have a look at the "Most active 6.3 employers" section for contributions to the 6.3 kernel, which amount to over 75% of the lines changed. https://lwn.net/Articles/929582/ https://lwn.net/Articles/929582/
  - throwaway892238 3y ago
    That is one open source project. There are millions.

api 3y ago

You forgot lock in. OIDC is an absolute nightmare for this. Watching everyone delegate all access control to Google and Microsoft is… I don’t even know what to say. It’s such an obvious trap but it’s convenient and convenience is the only thing anyone cares about. I’m gonna say I told you so in a few years. Nobody will care.

pphysch 3y ago
What "lock in"? If I use Google OIDC for my app, there's nothing stopping me from automatically migrating every Google user to a local account pre-populated with their Google claims, or from mapping those users to different identities, and permanently disabling Google OIDC.
- api 3y ago
  I’m talking about users. Can users change their login provider? Some apps allow this but most don’t.
  - clintonb 3y ago
    > Can users change their login provider? Some apps allow this but most don’t. You answered your own question. This is an issue with the app creator not supporting multiple providers, not with OIDC.
- donmcronald 3y ago
  I've never used it, but they can ban your app token, right? So I assume you need to make sure you're keeping your own up-to-date copy of all claims you have access to. > there's nothing stopping me from automatically migrating every Google user to a local account pre-populated with their Google claims I wonder your user retention would look like in that situation.
  - dikei 3y ago
    > I've never used it, but they can ban your app token, right? So I assume you need to make sure you're keeping your own up-to-date copy of all claims you have access to. That's why you should always provide multiple method of authentication. A simple way is fetching your user email from the OIDC provider, then use it for username/password authn. It's less convenient, but it prevents user from being locked out in case something's wrong with OIDC.

CrazyPyroLinux 3y ago

That comment reminded me so much of https://xkcd.com/927/ https://xkcd.com/927/