Imagine you run a company and provide multiple web applications for your customers. In the beginning, you probably created a user table and the authentication methods yourself, but from the second application onwards, you will think about using already made open source solutions.

That’s the situation I am in right now. I run multiple web applications, which each have their own auth mechanisms and user tables. This means, a user from App1 can’t use App2 unless he creates a new account.

OAuth#

Before I proceed, let’s have a short look how OAuth works:

  • OAuth Clients: That’s your typical web application which offers a login via 3rd parties like Google and Facebook
  • OAuth Servers / Providers: That is an identity provider like e.g. Google or Facebook

If you add OAuth to your app, most of the time you just add a OAuth client. That means, customers can log in with existing accounts from other services like Google or Facebook. But they can’t use their account at your app for logging into other apps.

When you provide a OAuth server, customers can log in into your applications and also login into 3rd party applications via the API of your identity server.

What OAuth means in my case#

If I would just add OAuth client functionality to my apps, then users could use e.g. their Google Account for all my apps, but my apps wouldn’t be connected with each other. Every single app would be displayed as 3rd party on the Google website, and every single app would need to authenticate with Google.

Because I want to provide one login for all Apps (single sign-on - SSO), just adding a OAuth client like most apps do, wouldn’t solve this problem.

I need a OAuth server which provides one single identity and one single login to all my apps. This means, all my apps become OAuth clients of my own OAuth server and my OAuth server itself is e.g. a OAuth client for other OAuth servers like Google. That way, a user could log in into my OAuth server with his existing Google Account and then continue to use all my apps.

So far the theory, now let’s look at the realization.

Backend-as-a-Service (BaaS)#

In the modern world, solutions like Supabase, PocketBase, Firebase, Appwrite or Parse Server are getting used more and more. One of the reasons is because they handle authentication for you.

There is just one big catch: Nearly all the BaaS solutions are just OAuth Clients! Every single application which you create on them will get their own user table and additionally, you often can’t connect custom OAuth Servers but only the popular ones like Google, Facebook, Twitter, GitHub,…

So my problem wouldn’t be solved, because I would still have different user tables and separate login processes. So every single app would be displayed on the Google website as a different OAuth client.

OpenID Connect / OAuth2 Servers#

Maybe you have already heard of applications like Keycloak, Ory Hydra, ZITADEL and SuperTokens. These are all auth providers which basically allow you to become some Identity provider like Google yourself.

It could be, that you already run a OAuth2 server without knowing it. E.g. Gitea has such a functionality built-in. I configured my Gitea instance to act as a OAuth server for e.g. my continuous integration and project management applications. I recently also found out, that my ERP Systems would also support auth via OAuth2, so I could set up all the apps inside my company to work just with the Gitea user auth.

If you set up an identity server like ZITADEL, then you have to integrate it into all your apps which may be time-consuming in the beginning, but it is absolutely rewarding:

  • You will never have to create a user table again
  • Login isn’t different for every app, but handled by one service only
  • If users are logged into your main provider, then all your client applications don’t need the user to enter username and password again
  • Modern auth servers support passwordless auth like FaceID, TouchID or Windows Hello

A bit more information about such services:

Keycloak#

One of the oldest and most famous auth servers. Complicated and written in Java.

Ory Hydra#

Modern, written in Go but still complicated in my opinion (Ory provides multiple packages for their auth solutions and it is hard to figure out which of them you need and how to configure them)

ZITADEL#

Modern, written in GoLang and in my opinion the one which is easiest to understand.

SuperTokens#

Another open source auth server written in Java.

Summary#

When I began exploring open source authentication solutions, I was thinking maybe some BaaS platform would help me. After figuring out what I wanted, it was clear that Backend-as-a-Service providers aren’t a solution for me and I had to look at a completely different kind of software category.

I don’t know which kind of OAuth2 Server I will stick with over the long time, but I am sure that I will use them.

Want to keep your Zitadel Instance uptodate?#

Checkout Autoupdate. One tool to update various software which has no built-in auto update functionality.