Posted on by richay

Authentik Federated Login with Google for SSO

Status: CURRENT
Last reviewed: 31 August 2026
Applies to: authentik with Google OAuth as a federated login source, then authentik SSO to self-hosted applications

In my setup I don’t use a normal authentik password for my everyday account. I authenticate to authentik with Google, then authentik handles the login to the rest of my web apps. One Google login, one authentik session, and most of the homelab stops asking me who I am every five bloody minutes.

What I’m actually doing

This sounds more complicated than it is because identity systems have managed to invent twelve names for “prove who you are”.

The important bit is:

Google
   ↓
federated login
   ↓
authentik
   ↓
SSO / OIDC / SAML / Forward Auth
   ↓
my self-hosted apps


Google is not directly logging me into Plex, Portainer, code-server, Nextcloud or whatever else I’ve decided needs a web interface this week.

Google authenticates me to authentik. Once authentik trusts who I am, authentik becomes the identity provider for the applications behind it.

authentik calls Google a Source. The application side uses authentik Providers.

Google OAuth Source
        ↓
     authentik
        ↓
Proxy / OIDC / SAML Provider
        ↓
    Application


Once I finally understood that direction, the whole thing became a lot less identity-management wizardry and a lot more “oh… that’s actually pretty logical”.

Why I use Google for the authentik login

My everyday authentik account is federated through Google rather than relying on another standalone password that I need to manage.

That gives me Google’s login security at the front door — including whatever MFA/passkey protection I have on the Google account — then authentik handles authorization and SSO for the homelab behind it.

The end result is lovely:

Open app
   ↓
app sends me to authentik
   ↓
already logged into authentik?
   ├── yes → straight back into app
   └── no  → authenticate with Google
                ↓
             authentik
                ↓
             back to app


So after I’ve logged into authentik with Google once, opening the next protected app is normally almost instant. It might bounce through authentik for half a second, but there’s no second password prompt because authentik already has my session.

Google Cloud OAuth or Google Workspace SAML?

authentik currently supports multiple ways to use Google as a federated identity provider.

  • Google Cloud OAuth — the easy option for a personal Google account or normal “Sign in with Google” setup. This is what this guide uses.
  • Google Workspace SAML — useful if you manage a Google Workspace organisation and want the Workspace tenant to act as the identity provider.

For my use case I just want Google authentication into authentik, so OAuth is the simpler path.

1. Create the Google OAuth application

In Google Cloud, create a project for authentik and configure the OAuth consent screen.

Then create an OAuth Client ID with the application type:

Web application


The important bit is the authorized redirect URI.

If my authentik installation was at:

https://auth.example.com


and I use the source slug google, the redirect URI is:

https://auth.example.com/source/oauth/callback/google/


The trailing slash and source slug matter. If the Google redirect URI and authentik source slug don’t match, OAuth will chuck a tantrum instead of politely guessing what you meant.

Google will give you:

  • Client ID
  • Client Secret

Keep the secret secret. Revolutionary advice, I know.

2. Create the Google source in authentik

In the authentik Admin interface go to:

Directory → Federation and Social login → New Source


Select:

Google OAuth Source


Give it something sensible:

Name: Google
Slug: google
Consumer key: <Google Client ID>
Consumer secret: <Google Client Secret>


The slug must match the callback URI we created in Google:

/source/oauth/callback/google/


Save the source.

3. Put Google on the authentik login screen

Creating the source does not automatically mean it appears on the default login page.

Go to:

Flows and Stages
→ Flows
→ default-authentication-flow
→ Stage Bindings
→ default-authentication-identification
→ Edit Stage


Under Source settings, add the Google source to Selected sources.

Now the authentik login page should offer Google as an authentication option.

4. First Google login and account enrollment

The first time you sign in through the Google source, authentik can enroll/create the corresponding authentik user.

Google doesn’t provide a separate traditional username field, so authentik’s default enrollment may ask you to choose one.

If you want new Google users to automatically use their email address as the authentik username, authentik documents an expression policy for the source enrollment flow.

The relevant idea is:

email = request.context["prompt_data"]["email"]
request.context["prompt_data"]["username"] = email
return False


I personally like email as the username here because the account relationship becomes bloody obvious when I’m looking at users later.

My authentik account does not use a normal password

This is the part that made me want federated login in the first place.

For my normal day-to-day account, Google is the login path. I don’t need another password prompt in authentik and then another one in every application behind it.

That means the trust chain is:

Google proves:
"Yep, this is richay"

authentik decides:
"Yep, richay is allowed into this app"

application receives:
"authentik says this is richay"

Everybody stops asking me for another bloody password.


Depending on the application, authentik may protect it with Forward Auth, or the application may use authentik directly through OIDC/SAML.

Forward Auth apps

Forward Auth is useful for applications that either don’t have useful SSO support or where I simply want the reverse proxy to enforce authentication before the request reaches the application.

With Traefik the basic flow is:

Browser
   ↓
Traefik
   ↓
authentik Forward Auth check
   ├── authenticated → app
   └── not authenticated → authentik login → Google if required


authentik currently supports both single-application and domain-level Forward Auth.

  • Single application — each app gets its own authentik application/provider and can have its own policies.
  • Domain level — one Forward Auth provider can cover multiple applications under the same parent domain, but you lose per-application policy control.

I prefer single-application when I care about different permissions. Domain-level is wonderfully lazy when everything under the domain is for the same trusted people.

OIDC / SAML apps

If an application supports proper OIDC or SAML, I generally prefer letting the application talk directly to authentik.

Then the flow is:

Application
    ↓
redirect to authentik
    ↓
authentik session already exists
    ↓
issue OIDC/SAML response
    ↓
application creates its own session


This is still single sign-on even though the application creates its own local session. The important bit is that I didn’t need to type another password.

Why it feels like Google logs me into everything

Technically Google only authenticates me to authentik.

But from my point of view:

1. Login to authentik with Google
2. Open Portainer
3. Logged in
4. Open another protected app
5. Logged in
6. Open another one
7. Still logged in

Me:
"well this is fucking lovely" :)


That’s because the browser already has a valid authentik session. Each application can send me through authentik, authentik recognises me, and the round trip finishes without asking me to authenticate again.

Important: keep a break-glass local admin

Do not make Google your only possible route into authentik administration.

If Google is down, your OAuth app is misconfigured, the client secret expires/gets replaced, DNS is cactus, or you accidentally break the authentik authentication flow, a federated-only admin account can leave you standing outside your own front door.

I keep a separate local administrator/recovery path that is not my everyday account.

Give it a strong unique password, protect it appropriately, don’t use it for normal browsing, and keep the details somewhere safe.

authentik also has a recovery-key mechanism if you’ve managed to lock yourself out. For a Docker Compose deployment, from the authentik Compose directory the current recovery command is:

docker compose run --rm server create_recovery_key 10 akadmin


That produces a recovery link valid for the specified number of minutes — ten in the example above.

Treat that URL like a password. Anyone holding it gets direct access as the selected authentik user while the key is valid.

Google account security now matters a lot

The convenience comes with an obvious trade-off: Google is now the first link in the authentication chain.

If someone compromises that Google account, they may also gain the ability to authenticate to authentik and therefore reach applications that account is authorised to use.

So I absolutely want strong MFA/passkeys and good account-recovery settings on the Google side. SSO is brilliant, but it also means the one key you’re carrying opens more doors.

This does not automatically give every Google user access

Federating Google into authentik and authorising applications are separate jobs.

authentik can bind policies to sources and applications, use groups, Grants or other policy logic to decide who actually gets access.

If you’re using a public Google OAuth application, don’t assume “has a Google account” should equal “welcome to my Proxmox dashboard, stranger”. That would be a fairly spectacular own goal.

Logging out

Because there are multiple sessions involved, logout can be slightly less magical than login.

  • Logging out of an individual application may only destroy that application’s session.
  • The authentik browser session may still exist, so revisiting the app can log you straight back in.
  • Logging out of authentik doesn’t necessarily sign you out of Google itself.

That’s not a bug — Google, authentik and the application are separate layers. SSO makes them feel like one thing right up until logout reminds you there are actually three sets of cookies having a meeting behind the scenes.

My end result

Google account
     ↓
authentik Google OAuth Source
     ↓
authentik session
     ↓
┌──────────────┬──────────────┬──────────────┐
│ Forward Auth │     OIDC     │     SAML     │
└──────────────┴──────────────┴──────────────┘
     ↓               ↓               ↓
self-hosted apps, without another pile of passwords


I log into authentik with Google, then authentik handles my identity for the rest of the web apps. The apps don’t need my Google password, Google doesn’t need to know about every random container in my homelab, and I get proper SSO without maintaining another password for every bloody service.

One front door, lots of rooms. Just make sure you’ve hidden a spare key somewhere sensible before welding the other doors shut 🙂

References

Leave a Reply

Your email address will not be published. Required fields are marked *