5 ms·

Oauth and enterprise auth has to be the worst thing ever made, it might be the most confusing and frustrating part of dealing with the cloud. Even the AI tools

Oauth and enterprise auth has to be the worst thing ever made, it might be the most confusing and frustrating part of dealing with the cloud. Even the AI tools took a year to just get basic Oauth working on headless systems without assuming you could open a browser. If they're going to go down the auth rabbit hole with RBAC/IAM/Workload identities?/service accounts and all the trash the big cloud providers have, I just hope to god they leave in the simple shit for personal use. I just want a damn API key, I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform.

jurgenaut23 4mo ago
I am tempted to agree with you because I could never quite wrap up my head around it, but I never had to implement OAuth beyond a brief skim through the doc for my own understanding. I always thought this complexity was there for some good reason (security?).
- messe 4mo ago
  > was there for some good reason (security?). To cover the myriad of (sometimes downright stupid) requirements that large enterprises have.
- iririririr 4mo ago
  far from it! it was just designed by comitee who both future proofed it and made sure it worked on low powered devices from 1971. i make a point to implement oauth from scratch, because using the overly complex libraries expose you to bugs such as attacker sending a token which the metadata just says "no encryption or signature. trust me bro", which is actually part of the spec if you combine some options. while in the real world, if google or apple sends you a token that is not always the same signature cypher (one of a dozen by the spec) you are better of threating as malicious, because it pretty much is. a manual implementation of a token consumer is about 20 lines... including downloading the provider keys and checking it (which most startups never do! allowing anyone to just sign a token as anyone)
- fmbb 4mo ago
  > I always thought this complexity was there for some good reason (security?). It's just design by committee.
- matja 4mo ago
  OAuth is designed so that an end-user never needs to see an API key (OAuth refresh/access token) or even know what one is. When it is implemented to the spec, that happens well. I think that most of the "just give me an API key" comments are from a <1% of end-users (developers) that know what an API key is, and are facing a broken OAuth implementation.
  - hvb2 4mo ago
    > and are facing a broken OAuth implementation. Or didn't bother to read the spec to understand why it's non trivial. Things like this are complex because attacks will force it to be. Also, the broken implementation might be an OIDC implementation that doesn't support client_credentials for example. Seen that many times and that does make it rather awkward to implement a server to server flow...
- mwwaters 4mo ago
  OAuth first and foremost is driven by getting secret information from, let’s say, Big Company. It’s understandable that there are many steps for some random Joe to get Google emails or Facebook DMs. OpenID piggy-backed on it by layering on new terms to an already complex scheme. The precious, secret information from Big Company in OpenID is just Email and maybe Name and Profile Picture. Then there’s a lot of ceremony for the service using OAuth to securely get that big secret (the user’s Email, which they had to supply in the first place directly to Relying Party).
willtemperley 4mo ago
What I don't understand is why OAuth is rarely talked about in a privacy context, however your OAuth provider knows all the sites you log into and when. It's a privacy nightmare.
- spaghettifythis 4mo ago
  Though given most people use gmail or outlook, the two main oauth providers (Google and Microsoft) will know anyway
  - willtemperley 4mo ago
    True they'd know which sites you've signed up to, but not the login times, unless the service emails you every time you log in.
    - kspacewalk2 4mo ago
      Every time you sign into an app, you get redirected to the auth provider to open a session there. So of course they know your login times.
      - willtemperley 4mo ago
        I don't think you followed the thread. I began discussing the OAuth privacy nightmare, then the counter point was that the with email auth providers know anyway, but they don't know the login times necessarily, unlike with OAuth.
  - v5v3 4mo ago
    Three main providers (Apple login is in nearly every iOS app and most websites)
- vintermann 4mo ago
  Your OAuth provider can also vouch for anyone who pretends to be you, if they so desire. They can give access to anyone, including themselves.
jofzar 4mo ago
We had a security report for a oauth vuln and it was the worst thing I have ever read, the whole thing is like spaghetti that "just works" until it doesn't because you feed it something similar. Never want to touch oauth, it's a fucked spec.
cad 4mo ago
Don't get me wrong but data shows that you will likely fail to keep that api key a as secret and you will also fail to revoke when it becomes necessary. You will definately not going to rotate it frequently as you should. Good thing about the OAuth2/OIDC is these things will not put the trust on the bearer of the api key, but on actual identity that needs to have the access.
- tasuki 4mo ago
  My data shows that zaptheimpaler has above average likelihood to keep their secret secret. > Good thing about the OAuth2/OIDC is these things will not put the trust on the bearer of the api key, but on actual identity that needs to have the access. And... you do not see the myriad of problems with that? What about the OIDC provider going rogue or getting compromised? How do you ensure whatever you use to authenticate with your OIDC isn't compromised? Many identity providers and identity bearers have terrible security practices. "Add a backup email in case you lose your 2FA. Nevermind it's the same email we use for password reset." Again, I trust zaptheimpaler to keep their secret much better than this whole pretend security theater.
  - tossitawayplz 4mo ago
    And I also trust myself to keep my secrets better than this whole pretend security theater too. I've never worked at an organization that handled their user's data/privacy/security even remotely close to how I handle my own and I wouldn't even consider myself all that paranoid. I have worked for some companies that really really should care too - there's just no incentive to really care and those in the org that try too do so will get ignored. The data breach letters I get in the mail a few times a year back me up on this.
- zigzag312 4mo ago
  Can you share source of this data? I have my doubts about the quality of the data, since OAuth2 is such a complex system with so many footguns. In the end there is always some long lived secret. What changes is just where and how it is stored, secured and used. I bet we can generalize to say that data shows that you will likely fail to properly secure any secret (including the ones used in OAuth2). EDIT: An example: https://news.ycombinator.com/item?id=37973937 https://news.ycombinator.com/item?id=37973937
raxxorraxor 4mo ago
Oauth is fine if you need the complexity, that is a lot of apps sharing common identity information. Then it certainly is superior to the classic workflow. I agree that it is too complex though and app to app auth is certainly not a focus. I often still use static common secrets and see no problem with that. I hate for apps needing to save passwords themselves, even if we have good tools today and the standard bcrypt call is reasonably safe. But then you need to reimplement password reset flows and all that ugly shit. Having that centralised is often I would recommend self-hosting an OIDC service for that matter. The control you get also allows you to easily comply with some laws like GDPR and cousins, because you need to just purge a user in a single system. Otherwise I thoroughly feel the frustration with IAM and the big providers. Ain't nobody got time for that and it is never a good and efficient solution.
- notpushkin 4mo ago
  > I would recommend self-hosting an OIDC service for that matter. Seconded. It is fairly easy to set up, and so much easier than the cloud IAM things. The only catch is, make sure you have some backup access to your OIDC provider in case it goes down. E.g. don’t host it on a server with SSH only accessible through VPN that is authorised using your OIDC provider, etc.
RVuRnvbM2e 4mo ago
It's the worst delegated authorisation system except for all the others that have been tried from time to time.
- badgersnake 4mo ago
  The original OpenID was fine.
  - notpushkin 4mo ago
    IndieAuth is fine (but I’ve yet to see an implementation out in the wild). Tailscale’s implementation of OIDC is nice: https://tailscale.com/docs/integrations/identity/custom-oidc https://tailscale.com/docs/integrations/identity/custom-oidc But all that only makes sense if you own a domain name.
    - wolrah 4mo ago
      > But all that only makes sense if you own a domain name. I have a hard time believing the venn diagram of "has a need for an auth provider" and "has at least one domain name" isn't just a a small circle almost entirely inside a large one, and the sliver on the outside is not for any reason other than stubborn refusal.
      - notpushkin 4mo ago
        Sorry, you’ve lost me. Which one is the small circle? My point was basically: OpenID 1 tried to let people log into websites using domain names. This is still possible to implement (and easier than OpenID, IMO), but people just don’t want to bother with domains.
aeneas_ory 4mo ago
OAuth2 is complex and often not the right tool. I wrote Ory Hydra and also a blog post when OAuth2 is/is not a good idea: https://www.ory.com/blog/oauth2-openid-connect-do-you-need-use-cases-examples https://www.ory.com/blog/oauth2-openid-connect-do-you-need-u... For API Keys we just launched Ory Talos (https://github.com/ory/talos https://github.com/ory/talos) - a perfect alternative for when OAuth2 is too much for the use case. There are use cases and security concerns that legitimize using OAuth2 - with specs like DPoP you can make these flows more secure. In my view the use cases presented here is a good one for OAuth2, but it certainly doesn’t make sense everywhere - complexity makes system harder to secure.
- usernametaken29 4mo ago
  Ory Hydra was one of the few tools I remember being actually good and lightweight and useable. Tried setting up and using KeyCloak for a while, absolute nightmare
jpc0 4mo ago
> I just want a damn API key, I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform Then implement that on your app... You are just generating a random key and storing a hash + salt. Auth is hard only applies to auth for many users. For your own auth this is dead simple and made even simpler if you use a half decent framework... If you are really worried about the implementation being insecure throw one of the many moderately frontier models at it, they are really not bad at finding issues in an auth system that simple.
dist-epoch 4mo ago
I run Codex in multiple disposable sandboxes and OAuth is such a fucking pain. I vibe-coded a project which just stores/allocates/shuffles codex auth.json files around. I have a codex instance that I manually authenticate multiple times with browser OAuth, then copy that auth.json in a store from where it's distributed to the sandboxes. And sandbox codex sometimes refreshes the authorization, so when that happens I need to send that auth.json back to the central store. Madness. One good thing GitHub Copilot has it that you can just give it a GH_TOKEN that is valid for 6 months and stop this browser login nonsense.
- throw1234567891 4mo ago
  What does codex's auth.json file have to do with OAuth?
- zaptheimpaler 4mo ago
  Yeah I was doing some similar stuff. I think I tried copying the auth file for codex or claude and even that didn't work - the tokens were somehow tied to some machine identifiers just to make it even more annoying. Claude Code has long lived oauth tokens which were working well for me, but then it turns out you can't use Remote Control if you use those, so I had to go back to the standard oauth web login trash everytime I spin up a new devbox. At every step the enterprise auth mindset makes my life more difficult by assuming I'm running some clownshow with bad code fully open to the internet unable to secure an API key, and gives me no way to just say "no thanks, i accept the increased risk ” and opt out of their junk.
deleted 4mo ago
[deleted]
the8472 4mo ago
OIDC can be relatively straight-forward (that is just a few JSON REST calls) if the provider isn't configured in a restrictive way. The .well-known/openid-configuration endpoint is quite helpful. Exchanging username+password (optionally with OTP) for a token is an option in the standard. The issue is that lots of deployments are quite restrictive "for security".
- OkayPhysicist 4mo ago
  OIDC is only barely more complicated than the minimum viable option for establishing someone's identity based on the word of a trusted third party. User shows up at your login flow. You assign them a big random number identifying their user session (this is your "state") User indicates an identity provider they'd like to use. You probably have a short list you trust. You ask that provider for the configuration data. You generate a big random number, that identifies this log in attempt as unique. This is your "nonce". You send the user, along with the state and nonce, to the trusted third party. (at their "authorization endpoint") The user proves to the trusted third party they are who they say they are. This isn't your problem. The user comes back to you with a claimed state and a code (a big random number assigned by the trusted third party). You check that the user's claimed state matches the state that you assigned them. This ensures that you end up authenticating the same user session as the one that started the login. You then reach out to the third party directly (to their token endpoint), with state and code in hand, and ask them "yo, a user session with this state just claimed you sent them to me with this code. Who are they?". And then the trusted third party sends back a token attesting "They are so and so". The one superfluous step is that, according the spec, you're supposed to then verify the signature of that token. It is unclear to me why this is in the spec, since I just made an https request to the trusted third party. The entire security model here has assumed that trusted third party is trusted.
ALLTaken 4mo ago
I would be so glad to see a short educational video about this. I wasn't aware of this and I think millions of other devs aren't either. Otherwise we'd never have adopted this nightmare. I love how simple SSH is with it's PK-Auth. The only challenge is session-invalidation and key-management, but that can be surely automated, no?
esseph 4mo ago
> I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform. Expect it. Security is hard and the companies with deep pockets are happy to pay the bill that meets their cybersecurity insurance requirements.
Saris 4mo ago
Plus I feel like it has completely ruined typical login flows, normally a PW manager would auto fill the username + password fields, but thanks to oauth we often get only a username field, or have to click 'login with password' or some other silly step first.
rockskon 4mo ago
OAuth 2.0 is a hate crime against security given its complexity.
- mwwaters 4mo ago
  When I really dove into it, I understood mostly why all the complexity was all there if I cared about data at the identity provider. When it’s only used for SSO, it’s extreme overkill.
adeptima 4mo ago
the original sin of internet - it’s not secure, and for many it’s not the bug it’s a feature to make money or gain power. all nested layers to cover up previous fails. example - nonce, state, encryption bumps in oidc/oauth2.1

jurgenaut23 4mo ago

I am tempted to agree with you because I could never quite wrap up my head around it, but I never had to implement OAuth beyond a brief skim through the doc for my own understanding. I always thought this complexity was there for some good reason (security?).

messe 4mo ago
> was there for some good reason (security?). To cover the myriad of (sometimes downright stupid) requirements that large enterprises have.
iririririr 4mo ago
far from it! it was just designed by comitee who both future proofed it and made sure it worked on low powered devices from 1971. i make a point to implement oauth from scratch, because using the overly complex libraries expose you to bugs such as attacker sending a token which the metadata just says "no encryption or signature. trust me bro", which is actually part of the spec if you combine some options. while in the real world, if google or apple sends you a token that is not always the same signature cypher (one of a dozen by the spec) you are better of threating as malicious, because it pretty much is. a manual implementation of a token consumer is about 20 lines... including downloading the provider keys and checking it (which most startups never do! allowing anyone to just sign a token as anyone)
fmbb 4mo ago
> I always thought this complexity was there for some good reason (security?). It's just design by committee.
matja 4mo ago
OAuth is designed so that an end-user never needs to see an API key (OAuth refresh/access token) or even know what one is. When it is implemented to the spec, that happens well. I think that most of the "just give me an API key" comments are from a <1% of end-users (developers) that know what an API key is, and are facing a broken OAuth implementation.
- hvb2 4mo ago
  > and are facing a broken OAuth implementation. Or didn't bother to read the spec to understand why it's non trivial. Things like this are complex because attacks will force it to be. Also, the broken implementation might be an OIDC implementation that doesn't support client_credentials for example. Seen that many times and that does make it rather awkward to implement a server to server flow...
mwwaters 4mo ago
OAuth first and foremost is driven by getting secret information from, let’s say, Big Company. It’s understandable that there are many steps for some random Joe to get Google emails or Facebook DMs. OpenID piggy-backed on it by layering on new terms to an already complex scheme. The precious, secret information from Big Company in OpenID is just Email and maybe Name and Profile Picture. Then there’s a lot of ceremony for the service using OAuth to securely get that big secret (the user’s Email, which they had to supply in the first place directly to Relying Party).

willtemperley 4mo ago

What I don't understand is why OAuth is rarely talked about in a privacy context, however your OAuth provider knows all the sites you log into and when. It's a privacy nightmare.

spaghettifythis 4mo ago
Though given most people use gmail or outlook, the two main oauth providers (Google and Microsoft) will know anyway
- willtemperley 4mo ago
  True they'd know which sites you've signed up to, but not the login times, unless the service emails you every time you log in.
  - kspacewalk2 4mo ago
    Every time you sign into an app, you get redirected to the auth provider to open a session there. So of course they know your login times.
    - willtemperley 4mo ago
      I don't think you followed the thread. I began discussing the OAuth privacy nightmare, then the counter point was that the with email auth providers know anyway, but they don't know the login times necessarily, unlike with OAuth.
- v5v3 4mo ago
  Three main providers (Apple login is in nearly every iOS app and most websites)
vintermann 4mo ago
Your OAuth provider can also vouch for anyone who pretends to be you, if they so desire. They can give access to anyone, including themselves.

jofzar 4mo ago

We had a security report for a oauth vuln and it was the worst thing I have ever read, the whole thing is like spaghetti that "just works" until it doesn't because you feed it something similar. Never want to touch oauth, it's a fucked spec.

cad 4mo ago

Don't get me wrong but data shows that you will likely fail to keep that api key a as secret and you will also fail to revoke when it becomes necessary. You will definately not going to rotate it frequently as you should. Good thing about the OAuth2/OIDC is these things will not put the trust on the bearer of the api key, but on actual identity that needs to have the access.

tasuki 4mo ago
My data shows that zaptheimpaler has above average likelihood to keep their secret secret. > Good thing about the OAuth2/OIDC is these things will not put the trust on the bearer of the api key, but on actual identity that needs to have the access. And... you do not see the myriad of problems with that? What about the OIDC provider going rogue or getting compromised? How do you ensure whatever you use to authenticate with your OIDC isn't compromised? Many identity providers and identity bearers have terrible security practices. "Add a backup email in case you lose your 2FA. Nevermind it's the same email we use for password reset." Again, I trust zaptheimpaler to keep their secret much better than this whole pretend security theater.
- tossitawayplz 4mo ago
  And I also trust myself to keep my secrets better than this whole pretend security theater too. I've never worked at an organization that handled their user's data/privacy/security even remotely close to how I handle my own and I wouldn't even consider myself all that paranoid. I have worked for some companies that really really should care too - there's just no incentive to really care and those in the org that try too do so will get ignored. The data breach letters I get in the mail a few times a year back me up on this.
zigzag312 4mo ago
Can you share source of this data? I have my doubts about the quality of the data, since OAuth2 is such a complex system with so many footguns. In the end there is always some long lived secret. What changes is just where and how it is stored, secured and used. I bet we can generalize to say that data shows that you will likely fail to properly secure any secret (including the ones used in OAuth2). EDIT: An example: https://news.ycombinator.com/item?id=37973937 https://news.ycombinator.com/item?id=37973937

raxxorraxor 4mo ago

Oauth is fine if you need the complexity, that is a lot of apps sharing common identity information. Then it certainly is superior to the classic workflow. I agree that it is too complex though and app to app auth is certainly not a focus. I often still use static common secrets and see no problem with that. I hate for apps needing to save passwords themselves, even if we have good tools today and the standard bcrypt call is reasonably safe. But then you need to reimplement password reset flows and all that ugly shit. Having that centralised is often I would recommend self-hosting an OIDC service for that matter. The control you get also allows you to easily comply with some laws like GDPR and cousins, because you need to just purge a user in a single system. Otherwise I thoroughly feel the frustration with IAM and the big providers. Ain't nobody got time for that and it is never a good and efficient solution.

notpushkin 4mo ago
> I would recommend self-hosting an OIDC service for that matter. Seconded. It is fairly easy to set up, and so much easier than the cloud IAM things. The only catch is, make sure you have some backup access to your OIDC provider in case it goes down. E.g. don’t host it on a server with SSH only accessible through VPN that is authorised using your OIDC provider, etc.

RVuRnvbM2e 4mo ago

It's the worst delegated authorisation system except for all the others that have been tried from time to time.

badgersnake 4mo ago
The original OpenID was fine.
- notpushkin 4mo ago
  IndieAuth is fine (but I’ve yet to see an implementation out in the wild). Tailscale’s implementation of OIDC is nice: https://tailscale.com/docs/integrations/identity/custom-oidc https://tailscale.com/docs/integrations/identity/custom-oidc But all that only makes sense if you own a domain name.
  - wolrah 4mo ago
    > But all that only makes sense if you own a domain name. I have a hard time believing the venn diagram of "has a need for an auth provider" and "has at least one domain name" isn't just a a small circle almost entirely inside a large one, and the sliver on the outside is not for any reason other than stubborn refusal.
    - notpushkin 4mo ago
      Sorry, you’ve lost me. Which one is the small circle? My point was basically: OpenID 1 tried to let people log into websites using domain names. This is still possible to implement (and easier than OpenID, IMO), but people just don’t want to bother with domains.

aeneas_ory 4mo ago

OAuth2 is complex and often not the right tool. I wrote Ory Hydra and also a blog post when OAuth2 is/is not a good idea: https://www.ory.com/blog/oauth2-openid-connect-do-you-need-use-cases-examples https://www.ory.com/blog/oauth2-openid-connect-do-you-need-u... For API Keys we just launched Ory Talos (https://github.com/ory/talos https://github.com/ory/talos) - a perfect alternative for when OAuth2 is too much for the use case. There are use cases and security concerns that legitimize using OAuth2 - with specs like DPoP you can make these flows more secure. In my view the use cases presented here is a good one for OAuth2, but it certainly doesn’t make sense everywhere - complexity makes system harder to secure.

usernametaken29 4mo ago
Ory Hydra was one of the few tools I remember being actually good and lightweight and useable. Tried setting up and using KeyCloak for a while, absolute nightmare

jpc0 4mo ago

> I just want a damn API key, I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform Then implement that on your app... You are just generating a random key and storing a hash + salt. Auth is hard only applies to auth for many users. For your own auth this is dead simple and made even simpler if you use a half decent framework... If you are really worried about the implementation being insecure throw one of the many moderately frontier models at it, they are really not bad at finding issues in an auth system that simple.

dist-epoch 4mo ago

I run Codex in multiple disposable sandboxes and OAuth is such a fucking pain. I vibe-coded a project which just stores/allocates/shuffles codex auth.json files around. I have a codex instance that I manually authenticate multiple times with browser OAuth, then copy that auth.json in a store from where it's distributed to the sandboxes. And sandbox codex sometimes refreshes the authorization, so when that happens I need to send that auth.json back to the central store. Madness. One good thing GitHub Copilot has it that you can just give it a GH_TOKEN that is valid for 6 months and stop this browser login nonsense.

throw1234567891 4mo ago
What does codex's auth.json file have to do with OAuth?
zaptheimpaler 4mo ago
Yeah I was doing some similar stuff. I think I tried copying the auth file for codex or claude and even that didn't work - the tokens were somehow tied to some machine identifiers just to make it even more annoying. Claude Code has long lived oauth tokens which were working well for me, but then it turns out you can't use Remote Control if you use those, so I had to go back to the standard oauth web login trash everytime I spin up a new devbox. At every step the enterprise auth mindset makes my life more difficult by assuming I'm running some clownshow with bad code fully open to the internet unable to secure an API key, and gives me no way to just say "no thanks, i accept the increased risk ” and opt out of their junk.

deleted 4mo ago

[deleted]

the8472 4mo ago

OIDC can be relatively straight-forward (that is just a few JSON REST calls) if the provider isn't configured in a restrictive way. The .well-known/openid-configuration endpoint is quite helpful. Exchanging username+password (optionally with OTP) for a token is an option in the standard. The issue is that lots of deployments are quite restrictive "for security".

OkayPhysicist 4mo ago
OIDC is only barely more complicated than the minimum viable option for establishing someone's identity based on the word of a trusted third party. User shows up at your login flow. You assign them a big random number identifying their user session (this is your "state") User indicates an identity provider they'd like to use. You probably have a short list you trust. You ask that provider for the configuration data. You generate a big random number, that identifies this log in attempt as unique. This is your "nonce". You send the user, along with the state and nonce, to the trusted third party. (at their "authorization endpoint") The user proves to the trusted third party they are who they say they are. This isn't your problem. The user comes back to you with a claimed state and a code (a big random number assigned by the trusted third party). You check that the user's claimed state matches the state that you assigned them. This ensures that you end up authenticating the same user session as the one that started the login. You then reach out to the third party directly (to their token endpoint), with state and code in hand, and ask them "yo, a user session with this state just claimed you sent them to me with this code. Who are they?". And then the trusted third party sends back a token attesting "They are so and so". The one superfluous step is that, according the spec, you're supposed to then verify the signature of that token. It is unclear to me why this is in the spec, since I just made an https request to the trusted third party. The entire security model here has assumed that trusted third party is trusted.

ALLTaken 4mo ago

I would be so glad to see a short educational video about this. I wasn't aware of this and I think millions of other devs aren't either. Otherwise we'd never have adopted this nightmare. I love how simple SSH is with it's PK-Auth. The only challenge is session-invalidation and key-management, but that can be surely automated, no?

esseph 4mo ago

> I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform. Expect it. Security is hard and the companies with deep pockets are happy to pay the bill that meets their cybersecurity insurance requirements.

Saris 4mo ago

Plus I feel like it has completely ruined typical login flows, normally a PW manager would auto fill the username + password fields, but thanks to oauth we often get only a username field, or have to click 'login with password' or some other silly step first.

rockskon 4mo ago

OAuth 2.0 is a hate crime against security given its complexity.

mwwaters 4mo ago
When I really dove into it, I understood mostly why all the complexity was all there if I cared about data at the identity provider. When it’s only used for SSO, it’s extreme overkill.

adeptima 4mo ago

the original sin of internet - it’s not secure, and for many it’s not the bug it’s a feature to make money or gain power. all nested layers to cover up previous fails. example - nonce, state, encryption bumps in oidc/oauth2.1