OIDC, OAuth2, and Proxy Provider in Authentik - how to protect any application

#

In this article, I’ll try to describe how to set up authorization in applications using OIDC technology or Authentik’s built-in proxy provider.

A bit of theory first.

What is OIDC

#

OIDC (OpenID Connect) is a modern authorization and authentication protocol built on top of OAuth 2.0. While OAuth2 on its own solves the problem of granting access rights (authorization), OIDC adds confirmation of the user’s identity (authentication).

Put simply:

OIDC = “who the user is” + “can they be granted access”, built on OAuth2.

How it works

#

1. The user tries to log in to an application.
2. The application sends them to the authorization server (Identity Provider) with a request essentially saying “I want to find out who this is”.
3. The user logs in with the provider.
4. The provider returns:
   • an ID Token - a JWT token with information about the user (name, email, ID, etc.).
   • an Access Token - an access token (as in OAuth2).
5. The application receives confirmed information about the user and lets them in.

Key concepts

#

ID Token

#

The main “feature” of OIDC - it contains data about the user:

• sub - a unique identifier
• name
• email
• issuance time, expiration time, etc.

OpenID Provider (OP)

#

The server that logs users in and issues tokens:
Keycloak, Authentik, Authelia, Zitadel, Google, GitHub, etc.

Relying Party (RP)

#

The application that trusts the provider and accepts its tokens.

Why OIDC is needed

#

• Centralized authentication (one login for many services).
• Better interoperability between different systems.
• Single Sign-On (SSO) capability.
• Easy integration with applications (via standard libraries).

Where it’s used

#

Practically everywhere:

• Keycloak
• Authentik
• Authelia
• Zitadel
• Google Sign-In
• GitHub Login
• Kubernetes (via Dex)
• Traefik / Nginx / Envoy as an OIDC proxy

What is OAuth 2.0

#

OAuth 2.0 is an authorization protocol that allows one service to gain limited access to a user’s resources on another service without transmitting the password.

Put simply:

OAuth 2.0 is a way to grant an application access “on behalf of the user” without revealing the login and password.

Why OAuth2 is needed

#

Common scenarios:

• You want to log in to a service via Google / GitHub / VK / Facebook.
• An application wants access to, say, only your photos, but not your email.
• Microservices want to securely “talk” to each other.

How it works (a very simple diagram)

#

1. The application wants to do something on behalf of the user → sends a request to the Authorization Server.
2. The user logs in on that server.
3. The server returns an Authorization Code.
4. The application exchanges the code for an Access Token.
5. The application uses the Access Token to access the API.

The user’s password remains known only to the authorization server.

Key OAuth2 entities

#

Authorization Server

#

Issues tokens (for example: Authentik, Keycloak, Authelia, Google).

Resource Server

#

The API or service that needs to be accessed (files, mail, profile, etc.).

Client

#

The application that needs access.

Access Token

#

The token the client uses to access resources.

Refresh Token

#

Allows obtaining a new Access Token without logging in again.

Grants (authorization types)

#

The most commonly used is the Authorization Code Flow, especially with PKCE for secure SPAs and mobile apps.

Others:

• Client Credentials - service-to-service authorization
• Refresh Token - refreshing tokens
• Device Code Flow - devices without a keyboard (TV, set-top boxes)
• Password Grant - deprecated, NOT used

Key takeaway

#

OAuth 2.0 does not confirm the user’s identity (who they are).
It only grants permissions (what they can do).

OIDC is used to confirm identity - it’s a layer on top of OAuth2.

What’s the difference between OIDC and OAuth 2.0

#

The short version

#

• OAuth2 is about access (“let the application do something on my behalf”).
• OIDC is about identity (“who is this user?”), built on top of OAuth2.

A real-life analogy

#

OAuth2 - power of attorney

#

You give a courier a power of attorney to pick up your package.
The courier doesn’t know who you are. They just received permission to perform an action.

OIDC - a passport + power of attorney

#

Now you’ve also shown your passport, and the service knows exactly who got access.

Key difference

#

Why OIDC came about

#

OAuth2 doesn’t say who the user is.
The application gets access, but doesn’t get profile data and doesn’t know who’s logged in.

To solve this problem, they created:

OIDC = OAuth2 + ID Token + UserInfo API + SSO standards.

Usage examples

#

OAuth2

#

• Grant an application access to the YouTube API
• A “Google Drive file access” scenario
• Microservice-to-microservice communication

OIDC

#

• Logging in via Google / GitHub
• Company-wide SSO
• Authorization in Keycloak/Authentik/Authelia/Zitadel

Summary (brief)

#

• OAuth2 says what can be done.
• OIDC says who is doing it.

Proxy Provider in Authentik

#

Proxy Provider in Authentik is a special type of provider that lets Authentik act as a transparent “proxy layer” between the user and an external service, adding authentication and access control where the service itself doesn’t support it.

Put simply:

Proxy Provider is a way to protect any web service, even if it doesn’t support OAuth2 / OIDC / SAML at all.

Authentik “inserts itself” between the user and the application as a reverse proxy.

How it works

#

1. The user tries to open the application.
2. The request doesn’t go directly to the application, but to the Authentik Proxy Provider, which works through nginx/traefik/caddy or is embedded as a sidecar.
3. Authentik:
   • checks whether the user is logged in;
   • if not - sends them to the login page;
   • after login, forwards the request on to the application.
4. The application receives headers containing information about the user, for example:
   • X-authentik-username
   • X-authentik-email
   • X-authentik-groups

The application accepts this data as fact - it doesn’t understand OIDC, but it can read headers.

When you need a Proxy Provider

#

When a service doesn’t have:

#

• OIDC
• OAuth2
• SAML
• LDAP

When you need to protect:

#

• Legacy web applications
• Admin panels (Grafana without SSO, Adminer, phpMyAdmin)
• Web UIs of Docker containers
• Home services on the local network
• APIs that can’t be modified

What the Proxy Provider gives you

#

• Authorization via Authentik (password, 2FA, OTP, WebAuthn).
• Access restriction by group / role.
• Passing user attributes via headers.
• Unified SSO for old applications.
• The ability to combine it with reverse proxies:
  • Traefik
  • Nginx
  • Caddy

Example: how it works with Traefik

#

Traefik redirects requests to the Authentik Proxy Provider → Authentik checks the user → returns them to Traefik → which forwards the request to the application along with headers containing the user’s information.

Flow diagram (Proxy Provider → Authentik → application)

#

sequenceDiagram
    participant U as User
    participant P as Proxy (Traefik / Nginx / Caddy)
    participant A as Authentik
    participant S as Service / Application

    U->>P: 1. Opens the application URL
    P->>U: Checks session<br/>If absent - redirect
    P->>A: 2. Redirects to the login page

    A->>U: 3. Login form (password, 2FA, WebAuthn)
    U->>A: Enters credentials

    A->>P: 4. Successful authentication<br/>Redirect back to the proxy
    P->>S: 5. Forwards headers<br/>with user data

    S->>U: 6. Access to the protected application

Step-by-step explanation, even shorter

#

1. The user → visits the service
2. Traefik/Nginx → redirects to Authentik
3. Authentik → asks for login / 2FA
4. Authentik → gives the proxy a “mark” that the user is authenticated
5. The proxy → adds headers with the user’s data
6. The application → accepts the headers → the user is in

Summary

#

Proxy Provider is a way to add SSO + protection + access control to any application, even if it doesn’t support that itself.

In the next article, we’ll move on from boring theory to more interesting practice.