[HN Gopher] Why use OpenID Connect instead of plain OAuth2?
___________________________________________________________________
Why use OpenID Connect instead of plain OAuth2?
Author : nathan-wailes
Score : 127 points
Date : 2023-06-26 15:57 UTC (7 hours ago)
(HTM) web link (security.stackexchange.com)
(TXT) w3m dump (security.stackexchange.com)
| commandlinefan wrote:
| Wow, this is the first comprehensible documentation on OAuth
| (post 1.0, which I actually did understand) I've ever seen. If
| the author of the StackOverflow post is on here, please publish a
| book, I'll buy it.
| nathan-wailes wrote:
| Wow, thank you so much for that compliment! I have a lot of
| other ideas / writings I want to try to post to Hacker News
| that I think people would find interesting, I honestly just
| posted this particular answer as a test. If you'd like, you can
| follow me on twitter: https://twitter.com/NathanWailes
| Zetice wrote:
| As someone who's had to implement these things for our B2B SaaS,
| I will say it'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/CD.
|
| 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's not easy
| to experiment (let's not even talk about vendor lock-in risks).
|
| I've found Cognito + CASL to be an... acceptable middle ground,
| as Cognito specifically "standardizes" the various
| OIDC/SAML/OAuth2 integrations such that I can rely on a certain
| structure within the JWT that apparently (based on this article)
| isn'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...
|
| I just wish I had the time to dive into the theory more. It seems
| interesting, but it's such a "boring" and "solved" thing that
| spending time on it doesn't really move the needle when it comes
| to stuff like customer acquisition.
| commandlinefan wrote:
| > such a "boring" and "solved" thing
|
| Well, don't forget it's also a security thing so no matter what
| DON'T IMPLEMENT IT YOURSELF YOU'LL GET IT WRONG so you sort of
| _have_ to mostly ignore the spec and start looking for a
| (probably commercial) implementation.
| SoftTalker wrote:
| I think the advice to "not roll your own" is usually in
| regards to encryption. Other security stuff is more
| reasonable to take on yourself; I'm not sure it's more likely
| that you'll use someone elses AuthZ framework any more
| correctly than you'll implement your own.
| yAak wrote:
| Yeah, I'm finding that I also need to understand
| authentication well enough that I COULD implement it, just
| to safely and correctly use someone else's implementation.
| andrewstuart2 wrote:
| I'm not quite sure what you're getting at, as OIDC and friends
| are very standardized when it comes to quite a few of the most
| important claims you would expect. There's an entire IANA
| registry [0] devoted to registered claims, in fact.
|
| As for authz choices, you're correct that it's almost always
| entirely dependent on the application, and subject to frequent
| change as applications evolve, and as e.g. user and group
| structure evolves as well. The "managers" group of today might
| turn into "directors" and "VPs" as the company grows, and
| "pictures" might soon incorporate "albums" as an optional
| grouping factor with its own permissions.
|
| In general, I would not really call
| authentication/authorization boring. There are components of it
| that are solved, but the reality of today is that people want a
| "share" link that they can paste in Slack and anybody can use
| it within seconds, and that kind of speed needs to be accounted
| for in authz, which is a significant engineering challenge.
|
| Papers like Zanzibar [1] are super interesting to read too. And
| at least to me, not boring at all.
|
| [0] https://www.iana.org/assignments/jwt/jwt.xhtml
|
| [1] https://research.google/pubs/pub48190/
| Zetice wrote:
| This is helpful, thanks!
|
| By "boring", I see that as a good thing; you _want_ auth to
| be boring, is my point. Intellectually stimulating it is in
| any event (I enjoy learning systems), but I want the process
| to be me learning how it 's done (the "boring"), not having
| to come up with novel solutions given my problem set (the
| "exciting").
| treve wrote:
| Yes they are standard, but this is akin to having a 'standard
| menu' at a restaurant. You're not getting every item on the
| menu, and for the ones that you do you could make
| modifications.
|
| OAuth2 and OpenID has many standards documents. A 'standard'
| OAuth2 server can be written in 30 minutes if you only care
| about 1 grant type and none of the extra features and 1
| flavor.
|
| But it can also take 6 months if you do want support for all
| the features such as introspection, revokating, multiple
| grant types, ID Tokens, etc.
|
| I wrote a bit about this issue here:
|
| https://evertpot.com/oauth2-usability/
|
| Note that this post is only about OAuth2, adding OpenID to
| the mix blows this problem up further.
|
| The key point is that OAuth2 and OpenID provide a framework
| for building authentication and identity systems, with a
| matrix of possible implementation details that often have to
| be communicated out-of-band. It's still _useful_ as a
| foundation, but picking an OAuth2 implementation is not as
| simple as just finding one that is OAuth2 compliant, you
| might have to dig deep and find out what parts you need and
| if your server implements them.
| nathan-wailes wrote:
| Thank you for the comment! I have to admit it's hard for me to
| follow what you're saying, I'm not sure what you mean by
| "innovation" or "middle ground", or where you're getting that
| the JWT structure (of an OIDC token?) isn't consistent.
| Zetice wrote:
| As a startup, I _very much_ do not want to innovate or be in
| any way "creative" when implementing functionality that
| isn't my company's core value prop for customers. So for
| something like AuthZ I want to be as conforming as possible
| to what "everyone else" is doing, and I want to do that as
| quickly and seamlessly as I can, so when I say "innovation"
| here, I'm saying I don't want to build a new library or write
| a new technology to do AuthN/Z that isn't well-trod ground.
|
| What I've experienced however, is that this isn't as easy as
| I expected. The "middle ground" here is between "inventing
| form whole cloth a bespoke library to solve AuthZ" and "do
| absolutely nothing whatsoever new". Using CASL in my infra's
| middleware to solve AuthN seems to be working for me. I can
| write the rules in a way CASL understands, and I was able to
| quickly implement the middleware without having to do
| anything crazy.
|
| As for "JWT structure being inconsistent" I mean to say that
| often I'm asked to "connect" many different providers, e.g.
| Google social sign-in, Okta, Auth0, etc., all of whom have
| their own way of structuring their JWT payloads (beyond the
| standard that is), and using Cognito as an intermediary has
| been helpful to avoid all of that, as again, I'm trying to do
| as little as possible myself.
| prpl wrote:
| Maybe it's worthwhile pointing out that even Auth0 is kind
| of exploring a bespoke way of doing this:
|
| https://auth0.com/docs/customize/extensions/authorization-
| ex...
| nathan-wailes wrote:
| Thank you for the clarification and for the tip about CASL
| and Cognito!
| AtNightWeCode wrote:
| Read up on AAAA
| nathan-wailes wrote:
| Thank you for the tip! I tried Googling the term but I didn't
| see anything jumping out at me as being a good resource to read
| up on it; do you have particular things you'd recommend?
| AtNightWeCode wrote:
| AAA seems to be more common today. Authentication,
| Authorization and Accounting. (Including Audit in
| Accounting.)
| nathan-wailes wrote:
| Thank you! Is there a particular book / article / video you
| recommend? Researching these things can be a nightmare so I
| find it helpful to ask for recommendations.
| AtNightWeCode wrote:
| This is more or less industry standard for some decades.
| You may try ChatGPT to guide you.
| msla wrote:
| Or don't use ChatGPT and avoid going off on a tangent
| when it hallucinates something.
| AtNightWeCode wrote:
| One may ask for sources... And the original Q in this
| case is so simple that even ChatGPT can easily answer it.
| It is not like there is room for opinions. It is basic CS
| projected on well known techs.
| msla wrote:
| > One may ask for sources...
|
| I know of a lawyer who did that. Didn't end well.
| 0cf8612b2e1e wrote:
| I come to this site to read opinions about things I do
| not know. Not for a variation of, "Google it"
| cratermoon wrote:
| Or try IAM: Identity and Access Management
| nathan-wailes wrote:
| I've heard that in the context of AWS, but I'm still not
| familiar with it. Do you recommend any articles in
| particular that give a good (brief) introduction to it?
| pan69 wrote:
| Maybe this Wikipedia page might get you started:
|
| https://en.wikipedia.org/wiki/Attribute-
| based_access_control
| 0xbadcafebee wrote:
| 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 wrote:
| 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-
| oau...
| carstenhag wrote:
| But who pays those? Only big companies have the will power and
| money to pay someone to only write standards.
| api wrote:
| 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.
| paulddraper wrote:
| ???
|
| OIDC doesn't increase lock in.
|
| Before, I had to (for example) generate AWS credentials,
| download them, and store them in GitHub Actions.
|
| But now, I can have GitHub Actions be directly authorized to
| access resources in AWS.
| pphysch wrote:
| 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 wrote:
| I'm talking about users. Can users change their login
| provider? Some apps allow this but most don't.
| carstenhag wrote:
| 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.
|
| One of them doesn't tell you how long tokens are valid for, and
| they are blaming it on their IDP (Salesforce).
|
| One of them just simply doesn't have the possibility for custom
| schemes (com.example.org://oauth-redirect) and blames their IDP
| (SAP Gigya).
|
| 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's language.
|
| 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!
| anderspitman wrote:
| The bizarre one I found is that Facebook is like 90% compatible
| with the OpenID Connect core profile (happy path at least). If
| they added token_endpoint to their coniguration[0] it would
| work, but instead I had to add custom code for FB just for that
| one thing.
|
| [0]: https://www.facebook.com/.well-known/openid-configuration
| [deleted]
___________________________________________________________________
(page generated 2023-06-26 23:01 UTC)