Just use OAuth2/OIDC.

Table of contents 🔗

Introduction 🔗

This article is about criticizing people reinventing the wheel, i.e., people who store user information in a database, built their own authentication flow, and make it hard to extend it. I will explain and show examples of OAuth2/OIDC implementations in details (step-by-step).

In 2020, I began to work on a project that I inherited it. It was a project about rendering a 3D map, which has user authentication (for some unknown reason decided by the client). My project was to make a mobile version with Unity and Android. I needed to:

1. Create a login page on Android.
2. Contact the API with the token to fetch data.

While this looked very simple, the project was using Symphony as the main web framework and, of course, the user authentication was "hand"-made and there was no public API. Now let me talk about what is Symphony (and similar frameworks) and what issues I encountered.

A critique about "users in database" and example of monolithic 🔗

Symphony, Django, NestJS and similar frameworks are server-side web frameworks that simplify the development of MVC (model-view-controller) applications, or in other words, applications that use a database and user interactions (some frameworks also include an administration dashboard!).

You might say, "Hey, these are frameworks that already include ways of implementing user authentication, what's the problem?". Well, there are several:

1. Coupled as hell: That's right. Even though the framework is said to have weak coupling, user authentication is already coupled in the framework. Just look at the documentation (Django, Symphony, NestJS), why is "creating a user in the database" the first thing suggested?! What about using an identity provider? Do you think engineers can maintain a user database for that long? What happens if they need to extend the connection to a mobile app? What if someone wants to use the user database in another project? You guessed it: Do it yourself.
2. Security: CSRF? XSS protection ? SQL injection? Remember why PHP is notorious for being hacked? Why should we implement these models when the identity provider is the one responsible for this situation?
3. Non-standard: None of the three given framework implements authentication the same way. And I'm not even talking about two-factor authentication.

To me, these three points are indicative of future bad decisions. Because it is coupled, it isn't easy to extend. Because the security must be manually implemented, it's not maintainable. Because it's not standard, your skills are not exportable.

Sure, a good Django engineer may implement everything easily and rapidly. But what if the framework where to die? What if the framework was full of security hole? These frameworks force an engineer to over-specialize. You basically become a framework engineer, not a software engineer. You become "vendor"-locked.

Well you may say again: "It's easier to implement the user in the database, after all, it's just next to the data.". And that's simply not, let me show you.

The existing standards for authentication 🔗

In 2006, some people said: "It sucks to have so many authentication services for each website. Hey, what if we were to implement a solution that delegate the authentication to one service?". Boom, OAuth. Of course, the road was much more complicated, but the reasoning was that. You can read more in the linked article.

Basically, for each website, you need to store your credentials and make sure that they do not expose the credentials to anyone else. Of course, that promise was certainly not respected.

There was also the issue of using third-party services: if someone were to create a service using a public API (for example Twitter), you would give your Twitter credentials to the third-party (which is an obvious no-no).

Overall, everything was resumed to one point: Separation of Concerns. The application needed to be separated from the authentication/authorization logic.

So what if we were to dedicate authentication to a service? Well, let's talk about the authorization logic.

And, the authentication flow with OAuth2 is the following:

1. The application (front-end/oauth2 client/user's browser) requests authorization to access resources from the user (also known as resource owner). (The authorization page is hosted on the OAuth2 Authorization Server, but it is the user that initiates the grant).

   

   (example with Dex, an OAuth2 provider)

2. After granting, the application redirects the user to the Authorization Server (OAuth 2.0).

3. The Authorization Server performs user authentication (by checking a code, token,etc.), and if successful, it issues an access token (OAuth 2.0).

4. The application receives the token and use it to make authenticated requests by the user.

5. The application can use the access token to access protected resources on the Resource Server (APIs).

With this architecture, we can delegate the access to a service like GitHub Auth, or Google Auth (the famous "Login with ..."). But that's not enough too, some APIs may need the identity of a user. Some services like GitHub publishes an API endpoint to fetches the user's information (/user), but it would be better if the OAuth2 provider could also give basic information of the user (like user ID, username, email, ...). To solve this issue, the OpenID Connect protocol, a.k.a. OIDC, was developed.

OpenID Connect is a protocol on top of OAuth2 which standardize fetching user information, allowing authentication and authorization at the same time by adding an ID token in the authentication flow.

If we take the OAuth2 flow and were to add OIDC capabilities, the step 3, 4 and 5 would be modified:

3. The Authorization Server performs user authentication (by checking a code, token, etc.), and if successful, it issues an access token (OAuth 2.0) and ID token.
4. The application receives the token and use the ID token to authenticate the user and retrieve basic profile information.
5. The application can use the access token to access protected resources on the Resource Server (APIs).

"Seems more complex than implementing your own authentication service with a framework"? Well, the flow certainly is. But there are already solutions that have implemented everything for you.

From a managed solution like Okta, Auth0 or Firebase Auth, to a self-hosted solution like Dex, Keycloak, Zitadel, they've managed to implement user federations, multiple third-party Identity Provider, and most importantly, a login page with the full flow implemented. That's called Single-Sign On (SSO), baby!

Hands-on example: One OIDC provider with Google Auth+OIDC with Go 🔗

To better convince you to NOT implement your own authentication service when you can use one existing service, let me show you how to implements OIDC. Remember why we are doing this: we do not want our app to store the user credentials. We delegate the user credentials to another service.

This example represents the type of services that are public (accessible to all), i.e. customers-facing.

As an example, let's use Google Auth with OIDC! An official guide on OIDC is available on Google.

To develop an OAuth2 application, you need a client ID, a client secret and information about the authorization endpoints. Since we use OIDC, we can use the discovery document to gather the information about the authorization endpoints.

1. Start by creating a Google Project. OAuth2 is free of charge and does not apply for the Identity Platform pricing (which is a different product similar to Firebase Auth or Dex, i.e, this is a managed service for multiple OIDC providers).

2. Go to the credentials page and create an OAuth2 credential.

   1. You will need to configure the OAuth authorization grant page. Just set to external and your email address.

   2. For the app, the most important part is to add a redirect URL. This is the callback URL of your application. Since we work locally, we set it to http://localhost:3000/callback. In production, this is the public endpoint accessible by the users, e.g, https://example.com/callback.

   3. After creating the app, store the OIDC Issuer, client ID and secret in a .env:

      1CLIENT_SECRET=GOCSPX-0123456789abcdefghijklmnopqr
      2CLIENT_ID=123456789012-0123456789abcdefghijklmnopqrstuv.apps.googleusercontent.com
      3OIDC_ISSUER=https://accounts.google.com
      4# Points to: https://accounts.google.com/.well-known/openid-configuration
      

3. Let's do our simple server. We will use the github.com/coreos/go-oidc package which parses the discovery document and already integrates a Verify function to check the ID token. For best practices, we also need to verify a CSRF token.

   Let's load the environment variables and run a simple server with CSRF protection:

    1package main
    2
    3import (
    4	"context"
    5	"encoding/json"
    6	"fmt"
    7	"log"
    8	"log/slog"
    9	"net/http"
   10	"net/url"
   11	"os"
   12	"time"
   13
   14	"github.com/coreos/go-oidc/v3/oidc"
   15	"github.com/golang-jwt/jwt/v5"
   16	"github.com/gorilla/csrf"
   17	"github.com/joho/godotenv"
   18	"golang.org/x/oauth2"
   19)
   20
   21func main() {
   22	_ = godotenv.Load()
   23	ctx := context.Background()
   24	redirectURL := "http://localhost:3000/callback"
   25	listenAddress := ":3000"
   26	oidcIssuerURL := os.Getenv("OIDC_ISSUER")
   27	clientSecret := os.Getenv("CLIENT_SECRET")
   28	clientID := os.Getenv("CLIENT_ID")
   29
   30    // TODO: load OIDC and OAuth2
   31
   32	csrfKey := []byte("random-secret")
   33	slog.Info("listening", slog.String("address", listenAddress))
   34	if err := http.ListenAndServe(listenAddress, csrf.Protect(csrfKey)(http.DefaultServeMux)); err != nil {
   35		log.Fatal(err)
   36	}
   37}
   

4. Load the OIDC and OAuth2 configuration:

    1	// ... env loading
    2	// Fetch and parse the discovery document
    3	provider, err := oidc.NewProvider(ctx, oidcIssuerURL)
    4	if err != nil {
    5		panic(err)
    6	}
    7
    8	// Initialize OAuth2
    9	oauth2Config := oauth2.Config{
   10		ClientID:     clientID,
   11		ClientSecret: clientSecret,
   12		RedirectURL:  redirectURL,
   13
   14		// Discovery returns the OAuth2 endpoints.
   15		Endpoint: provider.Endpoint(),
   16
   17		// "openid" is a required scope for OpenID Connect flows.
   18		Scopes: []string{oidc.ScopeOpenID, "profile", "email"},
   19	}
   20
   21	// TODO: write handlers
   22
   23	// server serve
   

5. Let's write the /login handlers which redirects to the OAuth2 login page:

    1	// Login page
    2	http.HandleFunc("/login", func(w http.ResponseWriter, r *http.Request) {
    3		// Fetch csrf
    4		token := csrf.Token(r)
    5		cookie := &http.Cookie{
    6			Name:     "csrf_token",
    7			Value:    token,
    8			Expires:  time.Now().Add(1 * time.Minute), // Set expiration time as needed
    9			HttpOnly: true,
   10		}
   11		http.SetCookie(w, cookie)
   12
   13		// Redirect to authorization grant page
   14		http.Redirect(w, r, oauth2Config.AuthCodeURL(token), http.StatusFound)
   15	})
   16
   17	// TODO: /callback handler
   

6. Let's now write the /callback handler, which happens after the user grant our OAuth2 application to access to user information:

    1package main
    2
    3import (
    4	"context"
    5	"encoding/json"
    6	"fmt"
    7	"log"
    8	"log/slog"
    9	"net/http"
   10	"net/url"
   11	"os"
   12	"time"
   13
   14	"github.com/coreos/go-oidc/v3/oidc"
   15	"github.com/golang-jwt/jwt/v5"
   16	"github.com/gorilla/csrf"
   17	"github.com/joho/godotenv"
   18	"golang.org/x/oauth2"
   19)
   20
   21type OIDCClaims struct {
   22	jwt.RegisteredClaims
   23	Name  string `json:"name"`
   24	Email string `json:"email"`
   25}
   26
   27func main() {
   28    // ...
   29	// Callback: check code with OAuth2 authorization server
   30	http.HandleFunc("/callback", func(w http.ResponseWriter, r *http.Request) {
   31		// Fetch code
   32		val, err := url.ParseQuery(r.URL.RawQuery)
   33		if err != nil {
   34			http.Error(w, err.Error(), http.StatusInternalServerError)
   35			return
   36		}
   37		code := val.Get("code")
   38
   39		// Check CSRF
   40		csrfToken := val.Get("state")
   41		expectedCSRF, err := r.Cookie("csrf_token")
   42		if err == http.ErrNoCookie {
   43			http.Error(w, "no csrf cookie error", http.StatusUnauthorized)
   44			return
   45		}
   46		if csrfToken != expectedCSRF.Value {
   47			http.Error(w, "csrf error", http.StatusUnauthorized)
   48			return
   49		}
   50
   51		// Fetch accessToken
   52		oauth2Token, err := oauth2Config.Exchange(r.Context(), code)
   53		if err != nil {
   54			http.Error(w, err.Error(), http.StatusUnauthorized)
   55			return
   56		}
   57
   58		// Fetch id token and authenticate
   59		rawIDToken, ok := oauth2Token.Extra("id_token").(string)
   60		if !ok {
   61			http.Error(w, "missing ID token", http.StatusUnauthorized)
   62			return
   63		}
   64
   65		idToken, err := provider.VerifierContext(
   66			r.Context(),
   67			&oidc.Config{
   68				ClientID: clientID,
   69			}).Verify(ctx, rawIDToken)
   70		if err != nil {
   71			http.Error(w, err.Error(), http.StatusUnauthorized)
   72			return
   73		}
   74
   75		claims := OIDCClaims{}
   76		if err := idToken.Claims(&claims); err != nil {
   77			http.Error(w, err.Error(), http.StatusUnauthorized)
   78			return
   79		}
   80
   81		// Do something with access token and id token (store as session cookie, make API calls, redirect to user profile...). Your user is now authenticated.
   82		idTokenJSON, _ := json.MarshalIndent(claims, "", "  ")
   83		fmt.Fprintf(
   84			w,
   85			"Access Token: %s\nDecoded ID Token: %s\n",
   86			oauth2Token.AccessToken,
   87			idTokenJSON,
   88		)
   89	})
   90    // ...
   

And that's should be it! We've used a library, but we can also do it with bare HTTP requests. For now, let's just use the go-oidc package. Similar libraries already exist for OIDC (Auth.js, AppAuth-Android, ...) though I prefer to implements manually since everything is standard.

Run the server (go run ./main.go) and go to the login page (http://localhost:3000/login) and see the Google OAuth2 grant page!

Now that we have an example running, there is one issue: we support only one authentication service. What if the user what to log in with GitHub instead of Google? Sure we can try to add a list of providers, but GitHub doesn't support OIDC! We cannot handle every edge case of every identity providers. We have to use an OIDC provider that connects to multiple providers.

That's why Firebase Auth, Google Identity Platform, Auth0, Okta, Dex and Keycloak exists. They are services that allow multiple identity providers and aggregate them into one unique endpoint.

Second example: Multiple providers in one with Dex+OIDC with Go 🔗

This time, to truly delegate the authentication part, we have to self-host a federated identity provider like Keycloak, Zitadel or Dex. We can also use a managed solution, like Firebase Auth.

Let's use Dex, a free, open source, lightweight solution to federated identity provider. Dex is an OIDC provider that facilitates authentication and identity management for applications by acting as an identity broker and supporting various authentication backends.

That's right, with OIDC, you can make proxies. After all, OIDC is all about delegation. So you can delegate authentication to a proxy that delegates to another OIDC provider.

Let's use Dex, our OIDC provider, which will delegate authentication to Google or GitHub, depending on the user's choice:

1. Create a configuration file dex/config.yaml with:

    1## This is us! The dex server!
    2issuer: http://localhost:5556
    3
    4## Endpoints configuration
    5web:
    6  http: 0.0.0.0:5556
    7
    8telemetry:
    9  http: 0.0.0.0:5558
   10
   11grpc:
   12  addr: 0.0.0.0:5557
   13
   14## Dex state, contains the users' login state.
   15storage:
   16  type: memory
   17
   18frontend:
   19  theme: dark
   20
   21## Our go application. This is a whitelist basically.
   22staticClients:
   23  - id: example-app # client ID
   24    redirectURIs:
   25      - 'http://localhost:3000/callback'
   26    name: 'Example App'
   27    secret: ZXhhbXBsZS1hcHAtc2VjcmV0 # client Secret
   28    #secretEnv: SECRET_ENV_NAME # Use 'secretEnv' instead of 'secret' to read environment variable instead of hard-coding.
   29
   30## The connectors!
   31connectors:
   32  - type: oidc
   33    id: google
   34    name: Google
   35    config:
   36      # URL to the OIDC Issuer
   37      issuer: https://accounts.google.com
   38      # Connector config values starting with a "$" will read from the environment.
   39      clientID: $GOOGLE_CLIENT_ID
   40      clientSecret: $GOOGLE_CLIENT_SECRET
   41      # Dex's issuer URL + "/callback"
   42      redirectURI: http://localhost:5556/callback
   43  - type: github
   44    id: github
   45    name: GitHub
   46    config:
   47      # Connector config values starting with a "$" will read from the environment.
   48      clientID: $GITHUB_CLIENT_ID
   49      clientSecret: $GITHUB_CLIENT_SECRET
   50      # Dex's issuer URL + "/callback"
   51      redirectURI: http://localhost:5556/callback
   52
   53## Enable self-hosted users. We've disabled that since our database is in-memory.
   54enablePasswordDB: false
   

2. Create an OAuth2 application on GitHub, set the redirect URI to http://localhost:5556/callback, and fetch the client ID and client Secret.

3. Edit the OAuth2 application on Google and add the redirect URI to http://localhost:5556/callback.

4. Create a dex/.env file which will be used for Dex:

   1GOOGLE_CLIENT_SECRET=GOCSPX-0123456789abcdefghijklmnopqr
   2GOOGLE_CLIENT_ID=123456789012-0123456789abcdefghijklmnopqrstuv.apps.googleusercontent.com
   3GITHUB_CLIENT_ID=01234567890123456789
   4GITHUB_CLIENT_SECRET=0123456789abcdefghijklmnopqrstuv
   

5. Create a dex/run.sh file with:

    1#!/bin/sh
    2
    3docker run --rm -it \
    4  --env-file "$(pwd)/.env" \
    5  -p 5556:5556 \
    6  -p 5557:5557 \
    7  -p 5558:5558 \
    8  --user 1000:1000 \
    9  -v "$(pwd)/config.yaml:/config/config.yaml:ro" \
   10  --name dex \
   11  ghcr.io/dexidp/dex:v2.37.0-distroless \
   12  dex serve /config/config.yaml
   

   Run it (chmod +x run.sh && ./run.sh).

Now let's modify the .env of the previous example:

1#.env
2CLIENT_ID=example-app
3CLIENT_SECRET=ZXhhbXBsZS1hcHAtc2VjcmV0
4OIDC_ISSUER=http://localhost:5556

And re-run the example go run ./main.go. And go to the login page: http://localhost:3000/login. You should be redirected to http://localhost:5556/auth, which is our OIDC provider.

And now, you can log in to multiple providers! The login page is also delegated, so we've barely changed anything!

Dex is almost stateless compared to the others solutions like Keycloak. This is why it is quite lightweight (20 MB only!). It doesn't really have a dedicated user store. If we want to store a user, we have to use an LDAP server (I recommend 389ds) or enable enablePasswordDB which I wouldn't recommend because you would couple a OIDC portal with a user store.

Third example: Fully self-hosted with 389ds+Dex+OIDC with Go 🔗

Note: Dex does NOT offer a sign-up (self-registration) page for LDAP. Use Keycloak or maybe Zitadel as an alternative.

If you work in a company, most of the time, you want to self-host your own user store. The "best" user store is often an Active Directory (AD) because of its flexibility to be able to plug onto anything like being able to synchronize Linux/Windows users from the AD.

There are a lot of solution to host an active directory. But I recommend only one: 389ds. Before I explain, let me explain LDAP.

Lightweight Directory Access Protocol is a protocol to store/find/manage users information. It's a very old protocol used for telecommunication. The latest version, LDAPv3, was published in 1998! To host an LDAP server, there is OpenLDAP, but managing it is a hellish experience. Example of usage:

 1cat << 'EOF' >> user.ldif
 2dn: uid=johndoe,ou=people,dc=example,dc=com
 3objectClass: top
 4objectClass: person
 5objectClass: organizationalPerson
 6objectClass: inetOrgPerson
 7uid: johndoe
 8cn: John Doe
 9sn: Doe
10givenName: John
11mail: johndoe@example.com
12userPassword: {SSHA}hashed_password
13EOF
14
15ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f user.ldif

This is quite complicated for nothing and you need to read the documentation often to be able to write LDIF files, which sucks when an incident occurs. Instead of using OpenLDAP, I recommend 389ds because it includes a CLI which allows quick commands. Example:

1dsidm create user --container "ou=people,dc=example,dc=com" --uid johndoe --cn "John Doe" --sn Doe --givenName John --mail johndoe@example.com --userPassword secretPassword

There is also FreeIPA, but it is a full-blown solution which also contains a DNS server, and is therefore difficult to containerize and maintain.

Let's just use 389ds for now:

1. Create a 389ds/.env:

   1DS_DM_PASSWORD=rootpassword
   2DS_SUFFIX_NAME=dc=example,dc=com
   3DS_ERRORLOG_LEVEL=256
   4DS_MEMORY_PERCENTAGE=25
   5DS_REINDEX=False
   

   The suffix represents the main directory. Users will be stored at ou=people,<suffix>.

2. Create a 389ds/run.sh:

    1#!/bin/sh
    2
    3# Create volume for data
    4docker volume create 389ds_data
    5
    6docker run --rm -it \
    7  --env-file "$(pwd)/.env" \
    8  -p 3389:3389 \
    9  -v "389ds_data:/data" \
   10  --name 389ds \
   11  docker.io/389ds/dirsrv:latest
   12
   

3. Run the script: chmod +x run.sh && ./run.sh.

4. Enter the shell:

   1docker exec -it 389ds bash
   

5. And run the initialization commands:

    1dsconf localhost backend create --suffix dc=example,dc=com --be-name example_backend # Create a backend (a backend is literally a database)
    2dsidm localhost initialise # Creates examples
    3# Create a user
    4dsidm -b "dc=example,dc=com" localhost user create \
    5  --uid example-user \
    6  --cn example-user \
    7  --displayName example-user \
    8  --homeDirectory "/dev/shm" \
    9  --uidNumber -1 \
   10  --gidNumber -1
   11# Set a user password:
   12dsidm -b "dc=example,dc=com" localhost user modify \
   13  example-user add:userPassword:"...."
   14dsidm -b "dc=example,dc=com" localhost user modify \
   15  example-user add:mail:example-user@example.com
   

6. Test with ApacheDirectoryStudio or with the LDAP tools:

   1ldapsearch -x -H ldap://localhost:3389 -b "ou=people,dc=example,dc=com"
   2# -x: Simple authentication
   3# -H: LDAP URL
   4# -b: Search base
   

   For groups:

   1ldapsearch -x -H ldap://localhost:3389 -b "ou=groups,dc=example,dc=com"
   

Now, let's reconfigure Dex to supports our LDAP server:

 1#config.yaml
 2#...
 3connectors:
 4  - type: ldap
 5    id: ldap
 6    name: LDAP
 7    config:
 8      host: <your-host-IP>:3389 # EDIT THIS. If you use docker-compose with root, you can set a domain name.
 9      insecureNoSSL: true
10      userSearch:
11        baseDN: ou=people,dc=example,dc=com
12        username: uid
13        idAttr: uid
14        emailAttr: mail
15        nameAttr: cn
16        preferredUsernameAttr: uid
17      groupSearch:
18        baseDN: ou=groups,dc=example,dc=com
19        userMatchers:
20          - userAttr: uid
21            groupAttr: member
22        nameAttr: cn

Now let's login at http://localhost:3000/login:

And you can enter the example-user credentials. Do note that Dex does not offer a Sign-Up (self-registration) page, the only way to add a user is to do what we did earlier:

 1docker exec -it 389ds bash
 2# In the container:
 3# Create a user
 4dsidm -b "dc=example,dc=com" localhost user create \
 5  --uid example-user \
 6  --cn example-user \
 7  --displayName example-user \
 8  --homeDirectory "/dev/shm" \
 9  --uidNumber -1 \
10  --gidNumber 1600
11# Set a user password:
12dsidm -b "dc=example,dc=com" localhost user modify \
13  example-user add:userPassword:"...."
14dsidm -b "dc=example,dc=com" localhost user modify \
15  example-user add:mail:example-user@example.com

You can use Keycloak or Zitadel which are solutions that are waaayyy larger but offer self-registration.

Conclusion 🔗

Remember my project? Well, for two months I built my own OAuth2 server when I could have simply exported the authentication layer to Firebase Auth. But the client was "Don't use another service, just use the one given", which I did. I developed the Android app with a working authentication page. Everything was homemade, including all protections (CSRF, XSS, user input validation, password validation, ...), except for modern protections (2FA, password-less, biometrics, ...). Not my f- job.

The project lasted only 6 months (fixed-term contract) and was abandoned 2 months later, probably because nobody could maintain such a project (not only because of the authentication layer, but also other technical aspects of the projects that I won't talk about). I really hated this project, with a stupid client who only had short-term vision and obsolete technical knowledge. You should NEVER develop software based solely on what you know, you should always compare new technologies with existing technologies, especially if the new technology becomes the norm. There's a difference between working in an innovative environment like 3D, where you can allow yourself the use of cutting-edge technologies like VR, versus an established environment like authentication, where OAuth2 may be young but became a standard.

Never ignore young technologies that spread like fire.

(OAuth2 is not even that young.)

I can do another article explaining why migrating/refactoring to new technologies is vital to the maintainability of a project, but not in this one. (There are a lot of reasons, but I would say the main reason is job opportunities.)

In conclusion, just use OAuth2 and OpenID Connect. Throw away the "home-made" solution, especially if implementing OAuth2 is just implementing two handlers and handling an access token. Use Firebase Auth if you can't self-host an LDAP with Keycloak, there is even libraries for it.

Next step is OAuth2.1 with PKCE, by the way. Don't miss it.

Bonus: If you are also asking: "Yeah, but it's harder to handle roles, now", maybe you forgot that Role-Based Access Control (RBAC) is simply about matching a user ID with a Role. Relationship is Many-to-Many, deal with it.

References 🔗

• Auth HTMX
• Auth HTMX Source Code
• Simple OIDC Example Source Code
• OAuth2
• OpenID Connect
• Dex