[HN Gopher] State of OpenID Connect Providers
___________________________________________________________________
State of OpenID Connect Providers
Author : Wronnay
Score : 70 points
Date : 2022-12-22 14:54 UTC (8 hours ago)
(HTM) web link (blog.m5e.de)
(TXT) w3m dump (blog.m5e.de)
| vinckr wrote:
| I would never advise anyone to write their own code to integrate
| with Open ID Connect. An open source solution pre-built from
| professionals like Ory Kratos or Keycloak saves you a lot of time
| and pain.
|
| https://github.com/ory/kratos
|
| https://www.keycloak.org/
| Wronnay wrote:
| I didn't used my own code - as mentioned I used Zitadel (a
| competitor to Ory and Keycloak) but it is still a pain in the
| ass.
| lakomen wrote:
| Why, the protocol is clearly defined. Especially clients have
| an easy life. Maybe stop promoting your own product with fear
| mongering
| penciltwirler wrote:
| Dex is also an interesting project in this space. It can act as
| an OIDC provider, but can be extended with other providers via
| "connectors".
|
| https://dexidp.io/
| rad_gruchalski wrote:
| Hi Vincent, hope you are well at Ory. Kratos without Hydra and
| Oathkeeper is pretty limited, no?
| vinckr wrote:
| Hey Radek, I am good, thanks for asking. Check in sometime!
| Limited compared to a full Keycloak install probably, but I
| think Ory Kratos is much easier to use and enough for most
| use cases. IMO you often dont need to use OAuth2 or
| Oathkeeper if you are not doing SSO, API access control or
| m2m communication. But of course there are many good options
| and approaches.
| rad_gruchalski wrote:
| Good to hear you are well.
|
| I stopped comparing the Ory stack to Keycloak some time
| ago. As you know, I like the modularity of Ory better than
| the single Keycloak deployment. However, what always gets
| me when deploying authn is that it releases the cat from
| the bag. Authz and additional sessions almost always come
| as a requirement right after.
|
| Last Kratos I looked at was 0.6 so fairly aged by now. Have
| you had a chance to make the Kratos/Hydra/Keto integration
| a little bit ... less abstract? From memory, integrating
| Kratos and Hydra reqired a ton of glue code one had to
| write themselves. That's the reason why I always reach for
| Keycloak.
| 0x457 wrote:
| Correct, it's not that it's limited, it's just different
| components of ORY stack. Kratos only does identity management
| and authentication (including being OIDC client). Oathkeeper
| does Identity Aware Proxy part. Finally, Hydra acts as OAuth
| 2.0 and OpenID Connect server.
|
| You can use either one of them separately or together. There
| is also no special glue to...glue them together, so you can
| use Hydra with different user management or Kratos with
| different OIDC server - my company at one point used Kratos
| for all user management, but Hydra was overkill, so we made
| our own OIDC server.
| commandlinefan wrote:
| > An open source solution pre-built ... saves you a lot of time
| and pain.
|
| I haven't looked at the linked solutions specifically, but I've
| only rarely found this to be the case for generic protocols
| like this ( _especially_ anything around OAuth or OpenID). The
| open source solutions I 've tried and given up on using always
| pull in hundreds of dependencies that have their own
| idiosyncracies as well as make a lot of undocumented
| assumptions and not be very well documented. Not to mention I
| still have to write code to use the "pre-built" solutions -
| usually more code than I would have had to write to just code
| the thing myself from scratch. They may be "better" from some
| perspective, but when I was working with OAuth, I tried (and
| tried and tried and tried) to use a pre-built solution for
| weeks until I finally gave up and just wrote my own in less
| than a day. Definitely longer and more painful to try to adopt
| somebody else's solution.
| mschuster91 wrote:
| > An open source solution pre-built from professionals like Ory
| Kratos or Keycloak saves you a lot of time and pain.
|
| Keycloak in itself is a pain to manage as well. Without
| Terraform, you're lost... and integrating stuff with Keycloak
| is a pain as well. I've tried and failed to integrate a self-
| hosted GitLab instance, for example - their docs [1] don't
| specify _anything_ how the Keycloak config is supposed to look
| like, the next best Google hit doesn 't either [2], and
| somewhen in the last two years the third Google hit [3] got
| outdated - the Keycloak OIDC configuration UI got completely
| reorganized and renamed. Other stuff like Atlassian is a pain
| to integrate with Keycloak OIDC as well.
|
| So, if _anyone_ could point me to a working configuration for
| modern Keycloak and GitLab, I 'd be really thankful. And if doc
| writers could specify a working Terraform, Ansible or whatever
| code that specifies the Keycloak configuration the application
| understands, I'd be even more thankful. OIDC is a horrible
| mess, I get it, but if your users can't get it to work because
| you specify nowhere what exact flavor and quirks of OIDC your
| application need, it reflects badly not just on Keycloak but on
| your application as well.
|
| /rant
|
| [1]
| https://docs.gitlab.com/ee/administration/auth/oidc.html#con...
|
| [2] https://github.com/ChathuminaVimukthi/Gitlab-SSO-
| implementat...
|
| [3] https://dheeruthedeployer.medium.com/gitlab-integration-
| with...
| scrollaway wrote:
| I don't have the code handy because I'm on my phone but we
| use keycloak for archlinux.org. You should be able to find
| the terraform and config for it all on our gitlab instance.
| motoboi wrote:
| Based on [1], I believe I can guide you through that:
|
| Given that your keycloak instance is running (and accessible
| to the user browser) at https://mykeycloak.net, its version
| is 17 or higher and you are using the realm named _master_.
|
| Given that your gitlab is at https://gitlab.example.com.
|
| At keycloak:
|
| 1 - create a new client, name it `gitlab` and set https://git
| lab.example.com/users/auth/openid_connect/callbac... as the
| root url (henceforth CALLBACK_URI)
|
| At keycloak, in the `gitlab` client settings screen, tab
| settings:
|
| 1 - Set `acess type` to `confidential`.
|
| 2 - Set `Direct Access Grants Enabled` to off.
|
| 3 - Set `Valid Redirect URIs` to `https://gitlab.example.com/
| users/auth/openid_connect/callbac...`* (that is the
| CALLBACK_URI followed by a *)
|
| 4 - Save it (A previously hidden credentials appear in the
| settings screen.)
|
| At keycloak, in the `gitlab` client settings screen, tab
| credentials:
|
| 1 - note down your client secret (something like
| HMPhR89hoxrcotAz9vWjEAlPCWRAx2MP), henceforth CLIENT_SECRET
|
| At your gitlab instance config file, setting
| gitlab_rails['omniauth_providers']:
|
| 1 - Set the content as in [1]
|
| 2 - Set args.issuer to https://mykeycloak.net/realms/master
|
| 3 - Set args.issuer.client_options.identifier to `gitlab`
|
| 4 - Set args.issuer.client_options.secret to CLIENT_SECRET
|
| Hope that helps. If that works for you, please write a public
| markdown github gist with this tutorial and the title "how to
| configure gitlab with keycloak?" this will help future google
| searchers. Be sure to reinclude the question "how to
| configure gitlab with keycloak?" as a title inside the gist,
| with the tutorial following, as google favors question and
| answer style.
|
| [1] = https://docs.gitlab.com/ee/administration/auth/oidc.htm
| l#con...
| gyulai wrote:
| Disappointing to hear that the ecosystem has fared that poorly.
| Are there really no companies doing this that aren't part of
| "surveillance capitalism"? When it first came out, I seem to
| recall that Norton was one of the companies offering Open ID.
|
| With GDPR there's a compelling business case for a service
| provider that acts as a clearing house for personally-
| identifiable data, so that, as a business, one would only ever
| deal with anonymized data, thus effectively outsourcing GDPR
| compliance.
| adamrezich wrote:
| I remember back in the mid-to-late 00s when OpenID seemed like
| the future...
| detaro wrote:
| OpenID Connect basically only shares the name with the OpenID
| from back then too.
| buttocks wrote:
| Not seen mentioned in this thread: Slack. Their oidc
| implementation is standard and well documented.
| jimkleiber wrote:
| A solution I've been using and really enjoy is Hello [0].
| Basically I can integrate Hello as the OIDC provider on my site
| (doing it on WordPress and Discourse for now but it can work for
| other sites) and then people login to their Hello wallet and then
| that logs into my site.
|
| Hello manages the social logins so I don't have to worry about
| adding a bunch of them (and update when new ones come out).
|
| It's also run as a cooperative, so I appreciate the business
| model behind it.
|
| [0]: https://www.hello.coop
| semitones wrote:
| Is the current state of affairs any better for SAML identity
| providers? I need to integrate SSO into our app and am also
| worried about having to write custom code for every identity
| provider we want to support.
| neeleshs wrote:
| If an IdP is SAML compliant, you only need to write code once.
| Of course, if you also want to authz based on IdP roles, you
| will need to have a mapper (from your app perms to IdP roles),
| but this is not because of differences in IdP
| iamjake648 wrote:
| We've been quite happy with Auth0 to solve this problem.
| semitones wrote:
| Auth0 is just another IDP, no? Could you elaborate?
| ctxc wrote:
| Auth0 can be used as the SP as well.
|
| https://auth0.com/docs/authenticate/protocols/saml/saml-
| sso-...
| yrro wrote:
| SAML delenda est
| zerkten wrote:
| You could integrate with something like Ping Federate. Then
| customers configure their identity provider to connect to your
| Ping Federate instance. I've seen the workflow for the support
| team to enable customers and it's not terribly difficult with
| the usual issues around expired certificates. Weird customers
| can be outsourced to Ping Federate support for guidance.
| Avamander wrote:
| SAML in my (anecdotal) experience seems to be worse, if it's
| supported at all.
| neeleshs wrote:
| Most IdPs support SAML IIRC
| Eduard wrote:
| But OAuth2 can be used for authentication as well, no?
| AtNightWeCode wrote:
| OIDC is a layer that simplifies the horrors of OAuth2.
|
| I am so fking looking forward to the death of this of fking
| grbage forum. I at some low point signed up to this forum. And
| I learned mostly nothing. And I am stilled annoyed cause it
| have a major impact at companies.
|
| ChatGPT beats 99.9% of HN users at everything when it comes to
| known facts, ChatGPT can easily tell, explain, and debunk this
| kind of fraud/ad content. The post is mainly incorrect.
|
| sry for hijacking yr comment
| MrGilbert wrote:
| Love the fact that this fella also decided to go for a numeronym
| for his website.
| pspeter3 wrote:
| I wish Discord supported OpenID Connect so I could use it as an
| authentication provider for Convex.
| yrro wrote:
| I've had pretty good experiences with Azure Active Directory's
| flavour of OpenID Connect. Multiple callback URIs are supported
| per app registration.
| rpep wrote:
| I spent a lot of time looking at this at work, and it was not
| smooth sailing for a complex workflow.
|
| The main issue is that B2B supports it pretty well, but if you
| need to say, do something like add an extra attribute
| dynamically to the JWT tokens, or allow automatic migration
| from a legacy IdP on first logon, you are forced to use B2C and
| Custom Policies which are effectively a programming language
| defined in XML and which are quite nasty to use. In addition to
| that, B2C doesn't fully implement all of OIDC so things like
| client credential flow are still in "Preview" at the moment.
| Deployment of custom policies is also only by use of a
| "Preview" API too. It didn't feel mature enough to me.
| davidspiess wrote:
| Azure B2C policies are a nightmare. Basically a programming
| language implemented in XML. Stay away from it.
| feurio wrote:
| I've had real issues with Azure. The (opaque, non JWT) refresh
| token seems to expire well before the access token is due to
| expire.
|
| Unless I force the access token to be refreshed 20 or 30
| minutes before the stated expiry time then the session gets
| killed off.
|
| It _works_ now, but there was a lot of head scratching and
| trail-and-error before I found out what was going on.
| Wronnay wrote:
| But is Azure AD free? When I checked it out, it looked like you
| have to pay for using it?
| jansommer wrote:
| Azure AD is 6$/mo per Premium P1 user as far as I know, but I
| think yrro is talking about Azure AD B2C and that's free up
| until something like 200,000 monthly active users (not
| affiliated with Azure but their calculator is my start page)
| hirsin wrote:
| AAD without all the security features (p1/p2) is free, with
| some limitations you'll quickly hit if using as your main
| directory. https://jumpcloud.com/blog/understanding-aad-
| pricing-free is a decent overview
| jansommer wrote:
| * 50,000 monthly active users
| yrro wrote:
| I think there's a very limited edition available for free.
| vbezhenar wrote:
| It's a shame that old OpenID was killed in favour of OpenID
| Connect. With OpenID I was able to log in to livejournal using
| OpenID implementation running on my own domain. With OpenID
| Connect I can only log in with blessed set of providers.
| Centralization sucks.
| api wrote:
| Are you sure that wasn't the point?
|
| OIDC is the biggest monopoly play in the industry right now and
| it's an absolute privacy nightmare. Almost nobody seems to even
| notice.
|
| Of course history has shown that people will trade literally
| everything for convenience so it will probably succeed. In the
| future if you get your Google account locked you won't be able
| to access your bank account or buy a plane ticket and Google
| will know everything you use at all times and be able to log
| into anything you use. But it'll be convenient.
| fghjklty wrote:
| yes, it was always the point.
|
| Microsoft was the main proponent and gave talks to every
| single government agency in the world in favour of it. never
| mentioning OIDC. while google was promoting it left and right
| to developers. also never mentioning OIDC. Only the
| open/decentralized parts.
|
| it was the classical embrace, Extend, Extinguish play. By now
| a classical move of both Microsoft and Google.
| notatoad wrote:
| OpenID supporting any provider would have been nice, but from
| my limited experience at implementing it suffered from the same
| issues as this blog post is describing - inconsistent
| implementations.
|
| OIDC is basically an admission that supporting any arbitrary
| provider had failed, and you need to actually test with each
| specific implementation before marking it as being supported.
| schwap wrote:
| The standards for this experience exist with OIDC Discovery[1]
| and Dynamic Client Registration[2], unfortunately they aren't
| used but it's not because it isn't supported.
|
| [1] https://openid.net/specs/openid-connect-discovery-1_0.html
| [2] https://openid.net/specs/openid-connect-
| registration-1_0.htm...
| kevincox wrote:
| Do any big-name providers support this? For example trying
| the webfinger request described in the first link on
| gmail.com returns a 404.
|
| As much as I love the ability to use my own server it is
| going to fall flat for the vast majority of users if you
| can't support at least one of
| Google/Facebook/Twitter/Microsoft.
|
| OpenID was supported by Google, Yahoo, MySpace, Wordpress and
| a few other big names. Not ideal but enough that you could
| basically expect most users to be covered.
| [deleted]
| tlarkworthy wrote:
| It's here for Google https://accounts.google.com/.well-
| known/openid-configuration
|
| Here for Microsoft
| https://login.microsoftonline.com/common/v2.0/.well-
| known/op...
| BillinghamJ wrote:
| And even for Apple: https://appleid.apple.com/.well-
| known/openid-configuration
|
| Facebook: https://www.facebook.com/.well-known/openid-
| configuration
| A321321 wrote:
| I am very surprised by this. I have successfully and
| interchangeably connected to many OpenId Connect providers, all
| without any issues. Providers like Azure, Ping, Octa, Auth0, ....
| brunoqc wrote:
| Maybe they want to sell you zitadel.
| Wronnay wrote:
| No - I am not an employee of Zitadel. That just the OpenID
| Connect Solution I decided to settle with. Keycloak and Ory
| Hydra looked to heavyweight for me.
| ffo wrote:
| Co-Founder here. Nice to hear this. Let us know where we
| can further improve our product.
| AtNightWeCode wrote:
| Agree, OIDC is the simplest and most versatile way to logon
| users and can be used in other scenarios. The discussion
| usually is where to store the tokens.
| fghjklty wrote:
| the point is the lack of control of your credentials if OIDC
| takes on instead of OID.
|
| if you log in with your github credentials and elon musk buy
| github and ban all the red heads, you just lost your accounts
| on azure, ping, octa, etc.
| gabrielsroka wrote:
| Nit, it's Okta. Also, Auth0 is owned by Okta
| voidwtf wrote:
| Yea, I'm also confused, Azure/Microsoft has the multiple
| redirect URLs feature the author mentioned in addition to not
| having an arbitrary user limit.
___________________________________________________________________
(page generated 2022-12-22 23:02 UTC)