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.
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.
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.
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.
But that's not the point. The goal of the discovery spec is that the user can enter an email and sign in with an OpenID connect provider of their choice. If I need to do an MX lookup and guess what identity provider they are using it doesn't solve the problem of needing to maintain a list of supported providers.
True, the "well-known" path seems to be in a random location but maybe that's a problem with the spec, you might expect it to be off the root of the email domain.
No. Generally this is because it is not a technical capability problem, but a business problem.
Often, sites which use OpenID for authentication either have no automated account recovery, or do recovery based on a verified email claim. This means those relying parties do indeed rely on the reliability and service support promises of the OP, as well as the validity of attribute data shared.
If ISPs or Google had been interested in providing webfinger-based discovery, we might have been able to create a decent UX around an assumption that your identifier was an email address, and that a local authentication process (including potentially an emailed code or link) was an acceptable fall-back. But there was never really critical mass for this to happen.
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.
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.
I wonder if a nonprofit privacy-oriented identity provider could work. All it does is provide OIDC to to any apps that want to integrate. On the backend users can login with any social provider or email, but the social providers would only ever see a login from the nonprofit.
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, ….
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.
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.
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.
> 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.
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_.
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.
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.
> 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.
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.
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.
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.
Sorry for the somewhat late answer, but we recently released Hydra 2.0 which makes the Kratos/Hydra integration much easier. You can also get it out of the box on the managed service (+ a ton of other features).
You need a simple consent page for the integration and that is it basically.
Check it out sometime :-)
A solution I've been using and really enjoy is Hellō [0]. Basically I can integrate Hellō 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 Hellō wallet and then that logs into my site.
Hellō 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.
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.
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.
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
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.
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)
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.
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.
