[HN Gopher] How Open ID Connect Works
___________________________________________________________________
How Open ID Connect Works
Author : iacguy
Score : 91 points
Date : 2024-01-04 16:03 UTC (6 hours ago)
(HTM) web link (blog.digger.dev)
(TXT) w3m dump (blog.digger.dev)
| simonw wrote:
| This is a really useful guide, but it's still not enough... every
| time I read something like this I get to a bit like this:
|
| "Create a role on AWS, add trust policy specifying which github
| org+repo are allowed to access this AWS role. Create an identity
| provider for github actions."
|
| I think need a full video of clicking around in the AWS console
| here, because the idea of having to figure out how to do that
| myself is horrifying to me.
| iacguy wrote:
| True. Will try to add a loom video to this article
| g_p wrote:
| I've seen the same issue with instructions for how to configure
| Keycloak as an OIDC provider - given Keycloak has so many
| options (some of which might well be security significant),
| you'd almost want a step by step explicit statement of what
| every setting should be, to get to a tested, validated and
| secure configuration.
|
| Which flow and service/grant etc seems to matter a lot, and be
| a good example where you'd want a very clear playbook of step
| by step instructions that you can hand off to someone else to
| unambiguously follow.
| simonw wrote:
| I've been wanting to setup GitHub Actions to use OIDC with
| Google Cloud (for deploying to Cloud Run) for a couple of
| years now, but I find the documentation completely
| inscrutable:
| https://docs.github.com/en/actions/deployment/security-
| harde...
| sigwinch28 wrote:
| The gist of it (pun intended) is that GitHub issues GitHub-
| issued (not issued by your cloud provider!) OIDC tokens to
| your job runs, and then your job exchanges those tokens for
| permissions with your cloud provider, which you have
| configured to trust tokens from GitHub.
|
| From experience, OIDC authentication to cloud providers
| from GitHub actions boils down to:
|
| 1. Get your GitHub actions workflow to be able to work with
| its own (GitHub) tokens by configuring workflow
| permissions.
|
| 2. Configure your cloud provider to verify tokens issued by
| GitHub actions OIDC server thingymabob (technical term).
|
| 3. Configure your cloud provider to grant permissions in
| that cloud provider (or issue its own tokens with those
| permissions) based on certain values in the verified GitHub
| tokens that is presented with. If your cloud provider
| trusts GitHub, then it can treat the values in the token
| (workflow name, branch run from, owner and name of GitHub
| repo) as trusted.
|
| 4. Use a GitHub action from your cloud provider to do the
| negotiation with your cloud provider when your job runs,
| performing the exchange configured in (3).
| simonw wrote:
| For me to follow that procedure I really do need
| meticulous step-by-step instructions, with a full set of
| screenshots for every interaction I need to have with any
| of the web consoles involved.
|
| If I ever get up enough courage to do this myself I'll
| take and publish those screenshots, but I'll probably
| continue to drag my heels for a few more years.
| j33zusjuice wrote:
| Jesus. We fucked with keycloak for like a minute at one of my
| past jobs where we used FreeIPA. Gave up, and just didn't use
| that functionality beyond whatever default stuff it m if it
| do. IAM is hard. I kind of enjoy it, but there's always a
| hundred other things I'm accountable for managing.
| jcadam wrote:
| What you're supposed to do is have an alcohol-fueled all-
| night session of modifying values in your Keycloak realm
| settings one at a time until it works. Then, you export the
| realm file and tell everyone not to mess with it.
| jcadam wrote:
| Enabling devs to do development work on their local machines
| with Keycloak in the stack is... fun /s.
| ParetoOptimal wrote:
| >I think need a full video of clicking around in the AWS
| console here, because the idea of having to figure out how to
| do that myself is horrifying to me.
|
| Or even better, was CLI commands or terraform.
| simonw wrote:
| CLI commands would be OK. Terraform wouldn't, because then
| I'll have to learn enough Terraform to run it - I'd rather
| minimize the number of extra tools I have to figure out here.
| sakopov wrote:
| It's not terribly difficult. I just threw a quick gist to help
| with this OIDC for Github in AWS -
| https://gist.github.com/sakopov/a66ef55f9713649e7d7b9b4a91d6...
| simonw wrote:
| Thanks for that, that's actually really useful - though I
| don't use cloudformation yet so I'd have to learn enough of
| that to put this into action.
|
| Love that you have to just happen to know about
| "1b511abead59c6ce207077c0bf0e0043b1382612" as the magical
| "known thumbprint" for GitHub!
| sakopov wrote:
| No worries, glad it's helping. AWS Console will
| automatically discover the thumbprint when adding a new
| provider, so I just grabbed it from there.
| spapas82 wrote:
| Great work! If you wanna understand how Open ID Connect works
| using _only_ HTTP requests /responses based on the specification
| (https://openid.net/specs/openid-connect-core-1_0.html) I've
| written an article here:
| https://spapas.github.io/2023/11/29/openid-connect-tutorial/
| igor47 wrote:
| Thanks, your article is what I was hoping for when I clicked
| the OP. I've been putting all my self hosted services behind
| OIDC recently using Authentic and I've been wanting to actually
| understand how the flow works under the hood, this really
| helped
| munchbunny wrote:
| OIDC (and the rest of the OAuth umbrella of stuff) is one
| category where every time I have to work with the protocols I
| think "there must be a less confusing way" and then have a
| failure of imagination for a simpler way to accomplish the same
| thing. I think it's because the protocols are conceptually
| simple, but the cryptographic parts, especially the PKI parts,
| make them intricate to understand exactly who is attesting or
| validating exactly what.
| shadowbanned4 wrote:
| 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.
| taeric wrote:
| Do you have a recommendation on what to use instead?
| shadowbanned4 wrote:
| HTTP basic auth, TLS with client certs.
| dboreham wrote:
| Those things don't do what OIDC does?
| shadowbanned4 wrote:
| They do them with much less complexity than OIDC.
| krooj wrote:
| They absolutely do not and also introduce a significant
| amount of overhead with respect to key/certificate
| management.
| chucke wrote:
| And security (basic auth is as good as sending clear text
| passwords).
| EthanHeilman wrote:
| Isn't Google moving toward phasing out TLS client certs
| in chrome/chromium?
| jeroenhd wrote:
| Do you have any source for that? I can't find anything
| online about this, but that would effectively kill
| browser mTLS.
| munchbunny wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I think this is mostly my own ignorance and inexperience
| working with AuthN, but I had a harder time than expected
| just figuring out how to add basic log in and session
| management to my website. I spent a long time reading all
| the official Cognito docs getting nowhere. Eventually I
| started searching on the web and finally found two guides
| that actually managed to explain what I was looking for:
| [0], [1].
|
| My philosophy toward authn right now is to never have to
| worry about security at all, so I want to completely
| minimize any personal responsibility towards managing
| passwords and tokens, first by outsourcing it as much as
| I can to products like Cognito, and failing that, by
| following best practices. My gripe with Cognito, as
| someone who doesn't know much about auth and would prefer
| to learn as little as possible (I just want to add logins
| to my site!), is that it doesn't give you an
| understandable API or user flow or best practices for
| implementing what I'd consider to be a "happy path" use
| case, unless you use Amplify. So if you're someone like
| me who is learning as they go, there are tons of footguns
| and mistakes you can easily expose yourself to.
|
| As an example: it's not obvious that using their hosted
| UI with a redirect, for USER_SRP_AUTH, should point to a
| backend endpoint hosted/managed by you that converts
| access codes to tokens and performs a second redirect
| back to your actual site. You could easily do the wrong
| thing and redirect back to your main site with the access
| code still in the URL params, and then issue a call from
| the webclient that converts that code to tokens ( Which
| is terribly insecure as it opens up an exploit - user
| could share that URL with another not knowing that the
| access code in the url params is sensitive and could
| allow others to sign into their account). In fact, that
| entire exploit/antipattern was never even mentioned
| anywhere in any docs I found, but it would be extremely
| easy to accidentally introduce by naively using Cognito.
|
| [0] https://aws.amazon.com/blogs/security/reduce-risk-by-
| impleme...
|
| [1] https://dev.to/jinlianwang/user-authentication-
| through-autho...
| taeric wrote:
| I confess I am far less worried about access tokens
| leaking to end users than I probably should be. Assuming
| folks are validating their audiences on tokens, I don't
| see as much danger on the implicit workflow.
|
| I'm also less clear on how the extra redirect there
| helps? If you are dependent on the user's client machine
| to follow the redirect anyway, they can still get
| middled, right? Compromised client doesn't follow the
| "code" redirect and instead directly calls to your oauth
| endpoint to get tokens. Since this is the "code" path,
| they can even get a session token that they can then
| start using on their own? Or do you lock down your oauth
| endpoints such that they can't be called? (Or is there
| more I'm mistakenly ignoring?)
| opportune wrote:
| The specific vulnerability I'm mentioning is if the user
| manually copies their post-redirect url (with access code
| in url params) and shares it with someone else.
| Specifically "hey check out this cool game!" (I'm making
| a game), sends a link, not knowing that nonsense after
| the site URL contains sensitive info that shouldn't be
| shared. And then some savvy user, or bot, hijacks their
| account.
|
| The extra redirect converts login.mainsite.url/?code=foo
| to mainsite.url with the code converted to tokens passed
| back via cookies. That way it's much harder for a user to
| leak account details accidentally. In this auth flow,
| Cognito hands off the login by redirecting to
| foo.bar/?code=baz which could leak baz if baz gets
| shared.
|
| My tokens' cookies themselves are same-site only/https
| only and not directly accessible, so they're protected
| against XSS AFAICT. AFAIK the only MITM security risk,
| once I got this working properly, is if something on the
| user's network sniffs and leaks url params to my login
| endpoint (not sure if TLS makes this impossible by
| encrypting the url path, hope it does, but not something
| I can easily workaround anyway) or injects arbitrary code
| to my backend (in which case almost everything is
| compromised anyway).
|
| I'm new to this auth stuff so I might be missing
| something, but I was surprised at the subtle security
| risk of Cognito's default redirect behavior once I
| noticed it.
| taeric wrote:
| Ah, I think I see. The concern is the web app not
| clearing the access token from the URL that a user
| accidentally shares? That or maybe URL logs of where a
| user has accessed would leak an access_token?
|
| This makes sense, and I think is compelling enough. The
| "code" is protected by some complicated effort in Cognito
| to make the code single use. (Right?)
|
| Thinking of my hypothetical, I don't think there is any
| real protection from a compromised client. This is data
| that you want to give to the user, and you have to do
| that through the client. But the redirect has to be
| followed by the user's client, right?
|
| To that end, you are probably still fine doing the code
| to token exchange using the web browser directly? Just
| not through the address bar, and instead with a post to
| the oauth endpoint. You can set the cookie locally, but
| no need to have another webpage involved.
| opportune wrote:
| I guess it depends on what you mean by a compromised
| client/ how it's compromised. The auth flow is:
|
| * mainsite.tld checks if user is unauthenticated/uses
| expired tokens. If so, redirect to Cognito UI hosted in a
| subdomain (auth.mainsite.tld) but managed by Cognito.
|
| * Cognito UI prompts user for username/email and
| password. Potentially also MFA. Handles password reset.
| Eventually also handles signup.
|
| * On successful sign in, Cognito redirects to my login
| endpoint with the access code in url params
| (login.mainsite.tld/?code=foo).
|
| * My login endpoint extracts the access code, talks to
| Cognito again to confer it to tokens. Returns tokens via
| cookies in a response that redirects to my main site
| (mainsite.tld). (This is what prevents the user from
| accidentally sharing their access code in url params,
| manually copied out of their browser address bar, if I
| had instead done this in the browser).
|
| * The main site now has working credentials; if the
| credentials go missing (because user cleared cookies) or
| expire (indicated in currently-unimplemented response
| when they interact with my authz/game server) they'll be
| redirected back to the same Cognito UI.
|
| I do not have control over how (url parameters) Cognito
| spits out the access code with this flow; still this flow
| is preferable to most others as at no point whatsoever am
| I responsible for managing user passwords, yet unlike a
| lot of new auth solutions that accomplish the same thing,
| users still actually have the option to sign in with
| passwords. What I do have control over is what redirects
| addresses are allowed out of Cognito, so afaict a
| compromised client (something bad that points to my
| login) can only redirect to my login endpoint which only
| redirects to my main site. There is no way to stop a
| compromised client (like a malicious browser and
| unsuspecting user) from doing bad things with the code or
| tokens but the same is true of anything entered into a
| browser ever, so that's not a problem worth caring about.
|
| But maybe I misunderstand (because I'm new to webdev too
| lol): what you're suggesting in that last paragraph might
| be possible if I can reliably get the browser to hide the
| access code url param from the address bar/history. I
| just didn't know how to do that from the browser without
| a redirect or reload. Even if that's possible I'd still
| consider it a pretty glaring footgun, because while
| (hypothetically) possible it's not necessarily obvious.
| mooreds wrote:
| > For AuthZ, things are not surprisingly outsourced
| heavily to the application side.
|
| There's some newer startups working on extracting and
| centralizing AuthZ functionality. Ones I'm aware of:
|
| * permit.io
|
| * cerbos.dev
|
| * Oso
|
| I'm sure there are more.
| akajla wrote:
| The specific challenge with authz in the app layer is
| that different apps can have different access models with
| varying complexity, especially the more granular you get
| (e.g. implementing fine grained access to specific
| objects/resources - like Google Docs).
|
| Personally, I think a rebac (relationship/graph based)
| approach works best for apps because permissions in
| applications are mostly relational and/or hierarchical
| (levels of groups). There are authz systems out there
| such as Warrant https://warrant.dev/ (I'm a founder) in
| which you can define a custom access model as a schema
| and enforce it in your app.
| steve1977 wrote:
| It's not because of cryptography, but because of abusing
| technologies not made for interactive stateful applications
| (i.e. HTTP, HTML etc.) for interactive stateful applications.
| nine_k wrote:
| I don't see how the display layer (HTML, CSS) or transport
| layer (http, TLS) are not suitable for mildly interactive
| stateful applications. All the state is on the server, except
| a few cookies.
|
| What they are "abusing" is the fact that the same browser,
| under user's control, may have access to many sites which
| don't by default trust each other. The user can attest that
| they should.
| opportune wrote:
| What's insane to me is that it feels like nobody has actually
| managed to make this easy for developers yet. If they have, I
| don't know about them.
|
| I would normally consider myself pretty competent, but I stood
| up my first fully featured website recently with logins and
| such, and it took me about 2 days of work to get AWS Cognito
| working (using their recommended USER_SRP_AUTH). That's not
| including 3rd party login functionality from Google and
| friends.
|
| Their documentation and UX is piss-poor unless you're willing
| to onboard your entire project to Amplify and enter npm-hell,
| which I wasn't. It's almost like they don't even want your
| business.
|
| I looked into using Auth0 instead and it didn't seem to be any
| easier. Better docs, seems like they're actually written by
| someone who both understands the auth problem domain and how to
| explain it to those that don't, but still complex.
|
| Yet when I was finished finally getting everything to work, it
| seems like the kind of thing you could easily package into an
| off-the-shelf product. It's just that existing products don't
| do it. Like why the fuck is there a guide explaining how to
| write a lambda to convert access codes to refresh tokens and
| persist them via cookies? That should be part of the Cognito
| platform!
|
| Honestly thinking of just starting my own auth SAAS with
| blackjack and hookers
| grinich wrote:
| Have you tried WorkOS? (I work there.)
|
| Makes it super easy to add SAML/SCIM to your app.
| https://workos.com/
|
| We also recently launched https://www.authkit.com/
| thelittleone wrote:
| WorkOS looks interesting from a features perspective but
| license model based on number of connected organisations is
| so high it will mean most SMBs (my clients) can't afford
| it.
| grinich wrote:
| Our customers typically just bundle our pricing within
| their own team/enterprise plan and pass through the cost.
| IT admins even within SMB orgs are happy to pay a couple
| hundred dollars a month more for the enhanced security of
| SAML auth. And small teams realistically don't need SAML,
| so you can add a minimum requirement on the number of
| "seats" (assuming that's how you bill).
| opportune wrote:
| Not yet, I'll give it a look next time I hack on my site.
| "Stripe for auth" is exactly what I'm looking for, and I
| know I still have a lot of auth head bashing left before I
| ship.
|
| I'll say though, my personal "customer demographic" ATM is
| more along the lines of someone who wants to get working
| user signups and auth and then never think about it again -
| so mentioning SAML/OIDC building blocks is a bit of a turn
| off for me. The reason is that I'm a solo dev trying to
| ship a browser-based multiplayer game, which I assign a low
| (maybe 5%) probability of ever becoming something with
| multiple people working on/turning into a real business -
| so I need auth, but would prefer to spend as much time as
| possible on the game itself, and don't have anybody to farm
| the work out to.
|
| But I'm happy to give workos a shot to see if it makes my
| life easier.
| grinich wrote:
| WorkOS is pretty tailored to folks building B2B apps
| where individuals will later be part of a team. (Think
| Dropbox, Figma, Asana, etc.)
|
| It's less of a fit for B2C products where user identity
| won't ever be associated with a company (like ecommerce,
| a game, or a dating app).
|
| The reason is that B2C apps actually have pretty
| different needs in terms of user identity. For example,
| most consumer apps will optimize for faster/higher
| conversion during signup and less security.
|
| But if WorkOS works for your use case, then you should
| definitely use it. Our free tier includes 1,000,000 MAUs,
| which is significantly higher than
| Auth0/Clerk/Stytch/etc. which start charging you around
| 10,000.
| mooreds wrote:
| Disclosure: I work for FusionAuth, an auth provider with
| a free community option.
|
| If I were in your shoes I'd probably use a library built
| into whatever framework you are using. Auth servers are
| powerful but are another architectural component you have
| to manage (even if it is a SaaS, there's still config to
| manage).
|
| Not sure what you are building it in, but if I were
| building it in rails, I'd use devise. If JS, maybe
| nextauth or passport.js.
|
| When you do this you have to accept certain risks (what
| if your user data gets breached, what if you want to add
| more functionality) but based on the little you've
| shared, I think a local solution is perfectly fine.
| aidos wrote:
| I had a look at this recently and the pricing was pretty
| wild. Am I right in understanding that the connection
| charge is effectively per organisation?
| grinich wrote:
| Yes, per organization. SAML/SCIM have no user limits.
|
| Hosted AuthKit is free up to 1,000,000 MAUs.
|
| https://workos.com/pricing
| wackget wrote:
| How does AuthKit compared to Auth0? Any major differences?
|
| Also what if you have an existing email-based account
| system which works fine - can you use AuthKit to add
| additional sign in methods like social without replacing
| your existing system?
| grinich wrote:
| The open-source nature of AuthKit is pretty different.
| You can build your own complete custom UI with the React
| components. Or build your own components from scratch and
| still use the WorkOS backend.
|
| Outside of that, it's pretty much a drop-in replacement
| for Auth0. We also have more features, like native SCIM
| provisioning and a streaming events API to keep your
| app's database in sync.
| alberth wrote:
| > _" I work there"_
|
| You don't just work there, aren't you the founder? :)
|
| https://news.ycombinator.com/item?id=22607030
| grinich wrote:
| Yep!
| ChadNauseam wrote:
| I use Supabase just for auth (use AWS for everything else)
| and it was incredibly simple. The only issue is that their
| docs for my niche use-case were slightly out of date, but it
| still only took me maybe 30 minutes total.
| mooreds wrote:
| Don't judge the identity server space by Cognito, I beg of
| you. There are a lot of other players out there (I work for
| FusionAuth, one of them) who are working to make this easier.
|
| Most have not been abandoned the way Cognito has. (Funny
| video on the topic:
| https://www.youtube.com/watch?v=x70EypnAH1Y .)
|
| I don't know why Cognito hasn't seen more improvement. From
| the outside, it seems like CIAM would be worth investing in
| as a cloud provider. Say what you will about Azure and GCP,
| they both have CIAM platforms that see more love than Cognito
| (Azure AD B2C, Firebase).
|
| > What's insane to me is that it feels like nobody has
| actually managed to make this easy for developers yet. If
| they have, I don't know about them.
|
| There are definitely folks making it easier to add
| login/logout to applications (I see some of them pop up in
| sibling comments, and we are working on that at FusionAuth as
| well). But some of these are component libraries to
| proprietary SaaS applications. In this case you lose some of
| the power and standardization of OIDC. That works great for
| some use cases and not so good for others. The nice thing
| about OIDC is that almost everyone works with it (or with
| SAML). Certainly more than proprietary session based
| authentication providers.
|
| I will tell you that as we are trying to make authentication
| simpler at FusionAuth, we have customers coming to us with
| pretty complicated use cases around federation, scale,
| automation, permissions and more. It's a balance to try to
| appeal to the developer who just wants authentication to work
| as well as the sophisticated customer who has these complex
| needs.
| JohnFen wrote:
| > It's a balance to try to appeal to the developer who just
| wants authentication to work as well as the sophisticated
| customer who has these complex needs.
|
| This sounds like there should be two solutions, one for the
| simpler case and one for the complex case, rather than
| trying to make one solution work for all use cases.
| opportune wrote:
| My thoughts exactly. I want a simple auth solution that
| _doesn't_ push me towards a full batteries-included
| platform like Firebase and Amplify. It seems like an
| underserved use case.
| throwawaaarrgh wrote:
| The crypto isn't complicated. What makes it complicated is the
| 10,000 different use cases they want the solution to work for,
| rather than one solution per use case, and a loose coupling
| interface for all of them.
| egnehots wrote:
| No, it can indeed be vastly simpler to handle auth. But you
| have to consider many complex aspects to provide a simple
| solution:
|
| - What are your real use cases (authentication, authorization,
| delegation?)
|
| - What is your threat model? (avoiding silly mistakes,
| preventing corporate espionage, defending against targeted
| attacks require very very different solutions)
|
| - How to integrate into your ecosystem (tech stack, actors,
| layers..)
|
| Then you might be able to remove some constraints. You might
| not need authorization delegation, stateless and readable json
| tokens.
|
| But often it's easier to not think too much about it and just
| use "an industry proven standard", and that is oauth2 and OIDC:
|
| a large auth umbrella to avoid looking at the sun.
| jeroenhd wrote:
| If you're writing software to authenticate users, the protocol
| is huge and complicated. That's why there are full prebuilt
| containers and SaaS authentication services that solve this
| problem. There are entire server implementations you can
| extend, but with tools like Zitadel and Keycloak ready to be
| configured and deployed for all manner of use cases, I don't
| see why you would.
|
| If you're just authenticating your client app against a server,
| it's pretty easy (all you need is two tokens and a URL for most
| librarlies). With some web servers (Apache, Caddy, the paid
| version of nginx) you can put that config in a location block
| and have it deal with the entire auth flow, so all your
| application needs to do is take the REMOTE_USER header or call
| /whoami to find out who the user is logged in as.
|
| Doing auth correctly is just hard. Personally, I treat it like
| I treat dates/times: use something someone else made, unless
| you have a particularly weird use case that nobody else
| supports.
| bob1029 wrote:
| I stopped spending mental cycles trying to parse these standards
| after taking myself on a ride with a completely DIY SAML service
| provider implementation.
|
| Today, we use OIDC & SAML to authenticate all of the things. But,
| I cannot explain how any of it works in terms of detailed
| protocol, certificate chains, etc.
|
| We actually have no in-house configuration along this axis
| because we only use products, such as web function runners, that
| live inside the IdP's platform. These can be trivially opted-in
| for MFA authentication with a single dropdown election if you are
| using Azure.
|
| If your mission is to build your own IdP platform and/or SP
| client libraries, then it totally makes sense to dive into this
| rabbit hole. Otherwise, make it someone else's problem. An
| occasional headline in the news about a token not expiring in
| time, etc, is not worth chasing unless you intend to compete
| directly with these providers and build your own identity
| platform. If Microsoft can get it wrong sometimes, so will you.
| mrweasel wrote:
| I've been working with Pythons Social Auth, because I didn't
| want to spend brain power trying to figure out exactly how OIDC
| works. Still that isn't enough, because OIDC isn't always
| implemented the same.
|
| E.g. Apparently you can return OIDC claims in two ways, nested
| or flat, but most clients do understand that, so if your server
| don't know how to do flat and your client only does flat, then
| you have a problem.
| patmorgan23 wrote:
| Yeah, lots of problems also come from JWT being a garbage
| Standard that doesn't actually standardize how to format a
| token.
| uxp8u61q wrote:
| Since OP seems to be the website author... You should remove or
| alter the ::selection style in your CSS. In dark mode, selecting
| text makes it illegible (white on white).
| cod1r wrote:
| I've recently been looking into passkeys and it seems much
| simpler than this.
| Manouchehri wrote:
| Personally, I would be worried about losing access to an
| account if I only relied on a passkey.
| jeroenhd wrote:
| I don't really understand this problem. Just click the
| "forgot password" link (perhaps "lost passkey" for passkey-
| first services?).
| tesdinger wrote:
| How can I backup a passkey on a sheet of paper?
| jeroenhd wrote:
| Passkeys and OIDC are not directly related. If all you want is
| "authenticate to AWS" then yes, passkeys would work, but so
| would a simple password, or a TLS client certificate, or
| whatever other technology you like for authentication.
|
| OIDC works for things like "use my employer's login to get
| access to AWS resources without having a separate AWS
| password".
|
| For certain OIDC authentication implementations, you can
| actually use passkeys. Standard passkeys should work perfectly
| fine with Keycloak's WebAuthn implementation, for example,
| either as a second factor or as the first factor in the login
| flow.
| xvinci wrote:
| Maybe I am really missing something seeing how other comments
| didnt mention it, but is this REALLY explaining how OIDC works? I
| don't see it.
| krooj wrote:
| No, there's no explanation.
| deathanatos wrote:
| No. This is more like a "how to configure an OIDC integration
| between Github Actions & AWS" tutorial. It _uses_ OIDC, but
| "How [OIDC] works" is too broad of a title for what the article
| ends up covering, IMO.
| smalu wrote:
| I do not known why OIDC has so many bad comments here. At my
| $company we are using Keycloak for multi-realm (multi-tenant)
| authentication of users and clients (applications). Yes, the
| learning curve is long for OIDC and even longer for Keycloak. The
| FreeMaker Template Engine is awful compared to Twig. Updates of
| Keycloak can break something, so better have proper test/stagging
| environment. But this is the tax for not implement something,
| that is not in core domain of organization.
|
| OIDC solves problems for OAuth2 like "every Identity Provider has
| different endpoints" with OpenID Connect Discovery (/.well-
| known/openid-configuration).
| carstenhag wrote:
| And then in real life I have to use the idm of 5 car
| manufacturers. Their devs being in South korea, China, US,
| Italy (we are in Germany).
|
| Impossible to manage meetings. Impossible to adhere to the
| standard. Impossible to demand that they use the well-known
| config. Impossible to agree on a good UX (by using sane config
| values for token validity).
| chucke wrote:
| > OIDC solves problems for OAuth2 like "every Identity Provider
| has different endpoints" with OpenID Connect Discovery
|
| Not really: https://www.rfc-editor.org/rfc/rfc8414.html
| starttoaster wrote:
| This doesn't really explain how OIDC works, it just explains the
| flow of requests a user would see if they're setting up OIDC for
| authentication between two systems for the first time.
|
| But beyond that, I'd say in future blog posts it would look a bit
| more professional to use some kind of architecture diagram making
| software, rather than somebody's napkin drawings. It's a little
| more difficult than it needs to be deciphering these graphics. To
| be entirely honest, I'd settle for mspaint-level quality if none
| of the free diagram making tools out there catch your eye.
| mooreds wrote:
| This was a nice overview of why you'd use OIDC to get short lived
| access tokens (in the pure sense, not in the OAuth sense) with a
| heavy emphasis on AWS. Not really an overview of OIDC, though.
___________________________________________________________________
(page generated 2024-01-04 23:01 UTC)