In the last days I tried to integrate multiple OpenID Connect Providers into my Applications (currently mostly Alphalerts and some dev projects)
So far, I only got Google to work, and even this is currently limited to 100 Users. In this blog post, I want to explain why the integration of OpenID Connect Providers is such a struggle by showing multiple examples.
But before I show the examples, you should know that there are not so many big OpenID Connect Providers compared to the big OAuth2 Providers. E.g. GitHub offers OAuth2, but is not a OpenID Connect Provider yet.
For reference, I use Zitadel as my own OpenID Connect Instance.
OpenID Connect is a protocol that allows users to authenticate themselves using a third-party service, such as Google or Microsoft, instead of creating a new account specifically for the service they are trying to access.
When a user wants to log in to a service that uses OpenID Connect, they are redirected to the third-party service to enter their login credentials. If the credentials are valid, the third-party service sends a unique token back to the service the user was trying to access, which confirms the user’s identity. This process allows users to easily log in to multiple services without having to remember multiple usernames and passwords, and it also allows service providers to authenticate users without having to store sensitive login information.
The Difference to OAuth2⌗
OAuth2 is a protocol that allows a user to grant limited access to their resources stored on one site, to another site, without having to disclose their login credentials. It is commonly used as a way for users to log in to third-party applications using their social media or other online accounts, without sharing their password.
OpenID Connect is built on top of OAuth2 and provides an additional layer of authentication on top of the authorization provided by OAuth2. While OAuth2 is focused on authorization and allows a user to grant access to their resources to another site, OpenID Connect adds the ability for the user to be authenticated and for the client to know the user’s identity. In other words, OAuth2 allows a user to authorize a client to access their resources, while OpenID Connect allows the client to authenticate the user and determine their identity.
So OAuth2 is a protocol for authorization, while OpenID Connect is a protocol for authentication and identity management. OAuth2 is used to grant access to resources, while OpenID Connect is used to verify the user’s identity and provide information about the user, such as their name and email address.
Google offers the best OpenID Connect implementation I have seen so far. You can set multiple callback / redirect URLs, which many Providers don’t offer yet.
There are just a few problems: If you set a Logo, your Application needs to be checked by a Google Employee and if you don’t get checked, your App is limited to 100 Users.
I couldn’t set up GitLab with Zitadel because GitLab doesn’t fully implement the OpenID Connect Spec.
prompt=select_account are not yet implemented by GitLab, but someone created a Issue for that.
Yahoo gives me a different problem. After the discovery document, they support
But currently, Yahoo always responds with
ES256. Because Zitadel currently just supports
RS256, this results in an error.
Other providers like netID, to which I come next, offer a dropdown menu in the Application creation step which lets you choose the algorithm. I send Yahoo an Email about this.
netID is a Foundation which was established in March 2018 by Mediengruppe RTL Deutschland, ProSiebenSat.1 and United Internet AG. The foundation pursues the goal of establishing netID as a European alternative to US single sign-on providers.
In difference to Yahoo, netID gives you the option to select
ES256 which is pretty nice.
However, netID only lets you define one Callback URL currently. Zitadel uses two different URLs for register and login, which makes this incompatible.
I also send a Mail to netID asking them to implement multiple Callback URLs.
OpenID Connect itself is pretty nice but despite being around since 2014, most providers just offer OAuth2 and the few providers which offer OpenID Connect have either not fully implemented the Spec or other weird Issues which makes it hard to use them.
Currently, it seems like you would have to write custom code for every different Provider - but exactly that should be prevented by such a Spec.
If you are interested in custom software development, you can take a look at my company.
You can use your Fediverse (i.e. Mastodon, among many others) account to reply to this post.