State of OpenID Connect Providers | Hacker News Reader

State of OpenID Connect Providers

blog.m5e.de

86 pointsWronnay64 comments

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.

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...

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.

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...

And even for Apple: https://appleid.apple.com/.well-known/openid-configuration

Facebook: https://www.facebook.com/.well-known/openid-configuration

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.

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.

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.

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.

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.

As someone who ran their own OpenID server for a couple of identities but has not touched this stuff for years, I have to ask:

Is there anything today that I can run (self-host) for a similar result?

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, ….

Maybe they want to sell you zitadel.

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.

Co-Founder here. Nice to hear this. Let us know where we can further improve our product.

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.

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.

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.

Nit, it's Okta. Also, Auth0 is owned by Okta

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/

> 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...

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.

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://gitlab.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.html#con...

Sadly, this does not work. The logs aren't exactly useful either:

==> /var/log/gitlab/nginx/gitlab_access.log <== 100.107.130.186 - - [23/Dec/2022:16:15:01 +0000] "POST /users/auth/openid_connect HTTP/1.1" 302 107 "https://git-xxx.xxx.de/users/sign_in" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36" -

==> /var/log/gitlab/gitlab-rails/application.log <== 2022-12-23T16:15:01.709Z: (openid_connect) Request phase initiated. 2022-12-23T16:15:01.735Z: (openid_connect) Authentication failure! Not Found: OpenIDConnect::Discovery::DiscoveryFailed, Not Found

==> /var/log/gitlab/gitlab-rails/application_json.log <== {"severity":"DEBUG","time":"2022-12-23T16:15:01.709Z","correlation_id":"01GMZW8DH3E10E8NBYKC65MCYR","message":"(openid_connect) Request phase initiated."} {"severity":"ERROR","time":"2022-12-23T16:15:01.735Z","correlation_id":"01GMZW8DH3E10E8NBYKC65MCYR","message":"(openid_connect) Authentication failure! Not Found: OpenIDConnect::Discovery::DiscoveryFailed, Not Found"}

Bring this to keycloak forum and I'll help.

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.

Hi Vincent, hope you are well at Ory. Kratos without Hydra and Oathkeeper is pretty limited, no?

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.

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.

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 :-)

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/

A bit like Keycloak?

Why, the protocol is clearly defined. Especially clients have an easy life. Maybe stop promoting your own product with fear mongering

> 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.

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.

[0]: https://www.hello.coop

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.

SAML delenda est

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.

SAML in my (anecdotal) experience seems to be worse, if it's supported at all.

Most IdPs support SAML IIRC

We've been quite happy with Auth0 to solve this problem.

Auth0 is just another IDP, no? Could you elaborate?

Auth0 can be used as the SP as well.

https://auth0.com/docs/authenticate/protocols/saml/saml-sso-...

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 remember back in the mid-to-late 00s when OpenID seemed like the future…

OpenID Connect basically only shares the name with the OpenID from back then too.

Love the fact that this fella also decided to go for a numeronym for his website.

I've had pretty good experiences with Azure Active Directory's flavour of OpenID Connect. Multiple callback URIs are supported per app registration.

But is Azure AD free? When I checked it out, it looked like you have to pay for using it?

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)

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

* 50,000 monthly active users

I think there's a very limited edition available for free.

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.

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 B2C policies are a nightmare. Basically a programming language implemented in XML. Stay away from it.

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.

Not seen mentioned in this thread: Slack. Their oidc implementation is standard and well documented.

I wish Discord supported OpenID Connect so I could use it as an authentication provider for Convex.

But OAuth2 can be used for authentication as well, no?

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

Reply on news.ycombinator.com