TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why use OpenID Connect instead of plain OAuth2?

215 pointsby nathan-wailesalmost 2 years ago

9 comments

0xbadcafebeealmost 2 years ago
When we let &quot;the industry&quot; 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&#x27;t even want to use it.<p>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.
评论 #36485993 未加载
评论 #36486606 未加载
评论 #36486042 未加载
评论 #36488524 未加载
carstenhagalmost 2 years ago
Bit off-topic I guess. Had to implement multiple logins with open Id connect of various huge car manufacturers (Korean, Italian, German) and huge oil companies. Holy croissant is it annoying. Every customer claims to be compliant to the specs, but you end up arguing so much over it.<p>One of them doesn&#x27;t tell you how long tokens are valid for, and they are blaming it on their IDP (Salesforce).<p>One of them just simply doesn&#x27;t have the possibility for custom schemes (com.example.org:&#x2F;&#x2F;oauth-redirect) and blames their IDP (SAP Gigya).<p>One of them has their own IDP, even has a debug screen in the html site, never causes any issues. Still requires some locale modification because of Norway&#x27;s language.<p>And then they configure it so that users are force-logged out after 1 or 7 days. When users expect to be kept logged in (just like at big apps like Google, Facebook, Instagram, etc). Agggh!
评论 #36486081 未加载
RandomBKalmost 2 years ago
This complexity is a security nightmare.<p>I write SPAs. I use Keycloak OIDC as the authentication layer. I have the SPA set up as a client using the &#x27;Standard Flow&#x27; with no Client Authentication[0]. I&#x27;ve carefully set my valid redirect URIs. I use the official Keycloak JS client and the standard JWT authentication implementation in my API server.<p>To this day I still have no idea if I&#x27;m doing everything correctly. I guess I&#x27;ll have to eventually hire some expensive security consultant to go over everything, but every step of this setup is filled with hidden gotchas:<p>* There&#x27;s multiple overlapping standards, each with a dozen different variants. The Keycloak OIDC config refers to OAuth2 over a dozen times.<p>* There&#x27;s thousands of blogs and articles, each 1000s of words long and each recommending different things. I have yet to find a concrete guideline for what a &#x27;sane default&#x27; set of choices are.<p>* Am I vulnerable to the issue described in the article? I guess I must be, given I don&#x27;t see the server-side JWT validator doing anything special beyond validating the signature, so there&#x27;s no validation of whether the token was generated for my app.[1][2]<p>* What are best practices for &quot;client scopes&quot;? I notice that the more I add the larger the JWT, but are there any gotchas to watch out for?<p>I think much of this boils down to there needing to be a published set of recommended defaults for common use cases, alongside some cleanup around deprecated&#x2F;not-recommended config options.<p>[0] Given client secrets can be trivially extracted.<p>[1] Though I guess the fact I&#x27;m only using my own auth server and there&#x27;s only one client means this isn&#x27;t a problem.<p>[2] Isn&#x27;t this how SSO works? One set of tokens to grant access to a bunch of different services?
评论 #36489738 未加载
评论 #36490557 未加载
Zeticealmost 2 years ago
As someone who&#x27;s had to implement these things for our B2B SaaS, I will say it&#x27;s been a lot less clear how to be as minimally innovative as possible when trying to weave in AuthZ into our product than it is to avoid innovation in something like IaC or CI&#x2F;CD.<p>Everything related to AuthZ ends up being so specific to every other decision you make about your infra, and companies that offer solutions tend to charge an arm and a leg so it&#x27;s not easy to experiment (let&#x27;s not even talk about vendor lock-in risks).<p>I&#x27;ve found Cognito + CASL to be an... acceptable middle ground, as Cognito specifically &quot;standardizes&quot; the various OIDC&#x2F;SAML&#x2F;OAuth2 integrations such that I can rely on a certain structure within the JWT that apparently (based on this article) isn&#x27;t consistent! And CASL I at least know how to insert into our infra, though I could see how it might not be the latest-and-greatest...<p>I just wish I had the time to dive into the theory more. It seems interesting, but it&#x27;s such a &quot;boring&quot; and &quot;solved&quot; thing that spending time on it doesn&#x27;t really move the needle when it comes to stuff like customer acquisition.
评论 #36483135 未加载
评论 #36483619 未加载
评论 #36481873 未加载
commandlinefanalmost 2 years ago
Wow, this is the first comprehensible documentation on OAuth (post 1.0, which I actually did understand) I&#x27;ve ever seen. If the author of the StackOverflow post is on here, please publish a book, I&#x27;ll buy it.
评论 #36483800 未加载
koolbaalmost 2 years ago
&gt; Relying on plain OAuth 2.0 for authentication is dangerous if you (the client) are just trusting ANY valid access token you receive that&#x27;s associated with that user as a reliable indicator that you&#x27;re receiving the request from the actual user, without knowing whether that access token was generated by the user trying to log into your site or if it was generated by the user logging into some other (malicious) website&#x2F;app.<p>That’s why there’s a “state” param that is passed between the source and the identity provider. It validates that the request indeed came from your system. Combined with prop CSRF protection you can ensure the user willfully logged into the system and the response from the IdP was intended for your system.
评论 #36489654 未加载
评论 #36489202 未加载
评论 #36487774 未加载
chuckealmost 2 years ago
I don&#x27;t understand what&#x27;s the point of this. So there is an answer that doesn&#x27;t answer the question in SO, and we glorify because it... is confirmation that yes, it&#x27;s bad?<p>OpenID is a specific layer on top of OAuth2. It standardised claims for authentication, scopes it down to the 2 credentials flows it can care about, and that&#x27;s core in a nutshell. It&#x27;s complicated, but so is HTTP, which most people don&#x27;t use directly anyway (and the same should be applied for OpenID, just use a blessed implementation, the OpenID foundation maintains a list of certified libraries you can rely on).
Paul-Craftalmost 2 years ago
Oh. I remember having to deal with this. What a fucking nightmare.<p>See, a large part of the problem comes from the fact that there are really <i>two</i> things you want to encapsulate under the word &quot;auth,&quot; (authentication and authorization), but OAuth2 only evan <i>attempts</i> one of them, and pretty badly at that.<p>That isn&#x27;t to say OpenIdConnect is perfect or anything, but at least when you&#x27;re doing the dance of encrypting a signed token (which, BTW, is the correct order, because in order to modify the payload and still have it validate, an attacker would need to break the encryption first in order to modify the payload into something malicious), having proper TTLs, and then, on top of that, having a way for the client&#x2F;user side to signal the server&#x2F;API resource side that &quot;hey, I&#x27;m done with this token a little early, so just ignore it forever now, mmmkay,&quot; you reduce the amount of damage an attacker&#x2F;malicious observer can do by intercepting one valid token.<p>Oh, but that&#x27;s only if both the client&#x2F;user side and the server&#x2F;API resource side each implement their half of the protocol 100% correctly... which is, of course, nontrivial and full of landmines for you to step on. [0]<p>Now, I stepped in this particular pile of bullshit because the company I was working for at the time was in health tech, and we had a client who thought they wanted to exchange EPHI (electronic personal health information -- you know, the kind of data that HIPAA makes radioactive with its massive financial penalties) with our servers to do some other random crap I didn&#x27;t really care about on their side. But, you can end up in the exact same place by replacing &quot;exchanging EPHI&quot; with &quot;accessing any confidential or sensitive data,&quot; so don&#x27;t think you&#x27;re safe from all this just because you&#x27;re not in the healthcare space.<p>Fortunately, in the end, our client realized that they did not, in fact, have the technical expertise and know-how to be able to deal with the security implications of what they were saying they wanted to do. So, our product and sales people talked them down to something that they could handle, and, which, fortunately, did none of give me headaches, cause me to lose sleep, or make me want to strangle people. And, that meant I could go back to paying attention to the things that actually mattered at the time, like making sure our RDS instance wasn&#x27;t going to keel over, hiring a couple new senior SWEs, and occasionally even leading the team.<p>I see that turned into a bit more of a rant than I had expected, so I&#x27;m just going to cut myself off here. I hope anyone reading this is able to learn from my experience and maybe not drive themselves crazy in the process.<p>Thanks for coming to my TED talk.<p>---<p>[0]: For instance: <a href="https:&#x2F;&#x2F;auth0.com&#x2F;blog&#x2F;critical-vulnerabilities-in-json-web-token-libraries&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;auth0.com&#x2F;blog&#x2F;critical-vulnerabilities-in-json-web-...</a>
AtNightWeCodealmost 2 years ago
Read up on AAAA
评论 #36483522 未加载
评论 #36488769 未加载