This middleware replaces the need for forward-auth and oauth2-proxy when using Traefik as a reverse proxy to support OpenID Connect (OIDC) authentication.
The Traefik OIDC middleware provides a complete OIDC authentication solution with these key features:
- Universal provider support: Works with 9+ OIDC providers including Google, Azure AD, Auth0, Okta, Keycloak, AWS Cognito, GitLab, and more
- Automatic provider detection: Automatically detects and configures provider-specific settings
- Automatic scope filtering: Intelligently filters OAuth scopes based on provider capabilities declared in OIDC discovery documents, preventing authentication failures with unsupported scopes
- Security headers: Comprehensive security headers with CORS, CSP, HSTS, and custom profiles
- Domain restrictions: Limit access to specific email domains or individual users
- Role-based access control: Restrict access based on roles and groups from OIDC claims
- Session management: Secure session handling with automatic token refresh
- Rate limiting: Protection against brute force attacks
- Excluded paths: Configure public URLs that bypass authentication
- Custom headers: Template-based headers using OIDC claims and tokens
- Comprehensive logging: Configurable log levels for debugging and monitoring
| Provider | Support Level | Refresh Tokens | Auto-Detection | Key Features | 
|---|---|---|---|---|
| ✅ Full OIDC | ✅ Yes | ✅ accounts.google.com | Auto-config, Workspace support | |
| Azure AD | ✅ Full OIDC | ✅ Yes | ✅ login.microsoftonline.com | Multi-tenant, group claims | 
| Auth0 | ✅ Full OIDC | ✅ Yes | ✅ *.auth0.com | Custom claims, flexible rules | 
| Okta | ✅ Full OIDC | ✅ Yes | ✅ *.okta.com | Enterprise SSO, MFA support | 
| Keycloak | ✅ Full OIDC | ✅ Yes | ✅ /auth/realms/path | Self-hosted, full customization | 
| AWS Cognito | ✅ Full OIDC | ✅ Yes | ✅ cognito-idp.*.amazonaws.com | Managed service, regional | 
| GitLab | ✅ Full OIDC | ✅ Yes | ✅ gitlab.com | Self-hosted support | 
| GitHub | ❌ No | ✅ github.com | API access only, no claims | |
| Generic OIDC | ✅ Full OIDC | ✅ Yes | ✅ Any endpoint | RFC-compliant providers | 
| Feature | Azure AD | Auth0 | Okta | Keycloak | Cognito | GitLab | GitHub | Generic | |
|---|---|---|---|---|---|---|---|---|---|
| ID Tokens | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | 
| Refresh Tokens | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | 
| Auto-Configuration | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 
| Custom Claims | Limited | ✅ | ✅ | ✅ | ✅ | ✅ | Limited | ❌ | Varies | 
| Group/Role Claims | Limited | ✅ | ✅ | ✅ | ✅ | ✅ | Limited | ❌ | Varies | 
| Domain Restriction | ✅ (hd claim) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | Varies | 
| Self-Hosted | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ✅ | ❌ | ✅ | 
| Enterprise Features | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | Varies | 
Important: GitHub uses OAuth 2.0 (not OpenID Connect) and only provides access tokens. Use it for API access only, not for user authentication with claims. All other providers support full OIDC with ID tokens and user claims.
Important Note on Token Validation: This middleware performs authentication and claim extraction based on the ID Token provided by the OIDC provider. It does not primarily use the Access Token for these purposes (though the Access Token is available for templated headers if needed). Therefore, ensure that all necessary claims (e.g., email, roles, custom attributes) are included in the ID Token by your OIDC provider's configuration.
The middleware has been tested with Google, Azure AD, Auth0, Okta, Keycloak, AWS Cognito, GitLab, GitHub (OAuth 2.0), and other standard OIDC providers. It includes automatic provider detection and special handling for provider-specific requirements.
This middleware includes advanced memory management features to ensure stable operation under high load:
- Bounded caches: All internal caches (metadata, sessions, tokens) have configurable size limits with LRU eviction
- Automatic cleanup: Background goroutines periodically clean up expired sessions and tokens
- Memory monitoring: Built-in memory leak detection and prevention
- Graceful degradation: Continues operating safely even under memory pressure
- Zero goroutine leaks: All background tasks are properly managed and terminated on shutdown
This middleware follows closely the current Traefik helm chart versions. If the plugin fails to load, it's time to update to the latest version of the Traefik helm chart.
- Enable the plugin in your Traefik static configuration:
# traefik.yml
experimental:
  plugins:
    traefikoidc:
      moduleName: github.com/lukaszraczylo/traefikoidc
      version: v0.7.10  # Use the latest version- Configure the middleware in your dynamic configuration (see examples below).
For local development or testing, you can use the provided Docker Compose setup:
cd docker
docker-compose up -dThis will start Traefik with the OIDC middleware and two test services.
The middleware supports the following configuration options:
| Parameter | Description | Example | 
|---|---|---|
| providerURL | The base URL of the OIDC provider | https://accounts.google.com | 
| clientID | The OAuth 2.0 client identifier | 1234567890.apps.googleusercontent.com | 
| clientSecret | The OAuth 2.0 client secret | your-client-secret | 
| sessionEncryptionKey | Key used to encrypt session data (must be at least 32 bytes long) | potato-secret-is-at-least-32-bytes-long | 
| callbackURL | The path where the OIDC provider will redirect after authentication | /oauth2/callback | 
| Parameter | Description | Default | Example | 
|---|---|---|---|
| logoutURL | The path for handling logout requests | callbackURL + "/logout" | /oauth2/logout | 
| postLogoutRedirectURI | The URL to redirect to after logout | / | /logged-out-page | 
| scopes | OAuth 2.0 scopes to use for authentication | ["openid", "profile", "email"](always included by default) | ["roles", "custom_scope"](appended to defaults) | 
| overrideScopes | When true, replaces default scopes with provided scopes instead of appending | false | true(use only the scopes explicitly provided) | 
| logLevel | Sets the logging verbosity | info | debug,info,error | 
| forceHTTPS | Forces HTTPS scheme for redirect URIs (REQUIRED for TLS termination at load balancer like AWS ALB) | false(when not specified) | true,false | 
| rateLimit | Sets the maximum number of requests per second | 100 | 500 | 
| excludedURLs | Lists paths that bypass authentication | none | ["/health", "/metrics", "/public"] | 
| allowedUserDomains | Restricts access to specific email domains | none | ["company.com", "subsidiary.com"] | 
| allowedUsers | A list of specific email addresses that are allowed access | none | ["user1@example.com", "user2@another.org"] | 
| allowedRolesAndGroups | Restricts access to users with specific roles or groups | none | ["admin", "developer"] | 
| revocationURL | The endpoint for revoking tokens | auto-discovered | https://accounts.google.com/revoke | 
| oidcEndSessionURL | The provider's end session endpoint | auto-discovered | https://accounts.google.com/logout | 
| enablePKCE | Enables PKCE (Proof Key for Code Exchange) for authorization code flow | false | true,false | 
| refreshGracePeriodSeconds | Seconds before token expiry to attempt proactive refresh | 60 | 120 | 
| cookieDomain | Explicit domain for session cookies (important for multi-subdomain setups) | auto-detected | .example.com,app.example.com | 
| audience | Custom audience for access token validation (for Auth0 custom APIs, etc.) | clientID | https://my-api.example.com | 
| strictAudienceValidation | Reject sessions with access token audience mismatch (prevents token confusion attacks) | false | true | 
| allowOpaqueTokens | Enable opaque (non-JWT) access token support via RFC 7662 introspection | false | true | 
| requireTokenIntrospection | Require introspection for opaque tokens (force validation, no fallback) | false | true | 
| headers | Custom HTTP headers with templates that can access OIDC claims and tokens | none | See "Templated Headers" section | 
| securityHeaders | Configure security headers including CSP, HSTS, CORS, and custom headers | enabled with default profile | See "Security Headers Configuration" section | 
| disableReplayDetection | Disable JTI-based replay attack detection for multi-replica deployments | false | true | 
⚠️ IMPORTANT - TLS Termination at Load Balancer:If you're running Traefik behind a load balancer (AWS ALB, Google Cloud Load Balancer, Azure Application Gateway, etc.) that terminates TLS:
- You MUST set
forceHTTPS: truein your configuration- Without this setting, redirect URIs will use
http://instead ofhttps://, causing OAuth callback failures- This is especially critical for AWS ALB which may overwrite the
X-Forwarded-ProtoheaderDefault behavior:
- When
forceHTTPSis not specified in your config → defaults tofalse(Go zero value)- When
forceHTTPS: trueis explicitly set → always useshttps://for redirect URIs- When
forceHTTPS: falseis explicitly set → scheme detection based on headers/TLSSee GitHub Issue #82 for details.
The middleware supports two modes for handling OAuth 2.0 scopes, controlled by the overrideScopes parameter:
By default, the middleware uses an append behavior for OAuth 2.0 scopes:
- Default scopes are always included: ["openid", "profile", "email"]
- User-provided scopes are appended to the defaults with automatic deduplication
- The final scope list maintains the order: defaults first, then user scopes
When overrideScopes is set to true, the middleware uses replacement behavior:
- Default scopes are not automatically included
- Only the scopes explicitly provided in the scopesfield are used
- You must include all required scopes explicitly, including openidif needed
Default behavior (no custom scopes):
# No scopes field specified
# Result: ["openid", "profile", "email"]Default append behavior:
scopes:
  - roles
  - custom_scope
# Result: ["openid", "profile", "email", "roles", "custom_scope"]Overlapping scopes with append (automatic deduplication):
scopes:
  - openid      # Duplicate - will be deduplicated
  - roles
  - profile     # Duplicate - will be deduplicated
  - permissions
# Result: ["openid", "profile", "email", "roles", "permissions"]Using override mode:
overrideScopes: true
scopes:
  - openid
  - profile
  - custom_scope
# Result: ["openid", "profile", "custom_scope"]Empty scopes list with default behavior:
scopes: []
# Result: ["openid", "profile", "email"]Empty scopes list with override mode:
overrideScopes: true
scopes: []
# Result: [] (Warning: empty scopes may cause authentication to fail)The default append behavior ensures essential OIDC scopes are always present, while the override mode gives you complete control over the exact scopes requested from the provider.
The middleware provides comprehensive support for Auth0 audience validation to prevent token confusion attacks. Auth0 can issue tokens in three different scenarios, each requiring specific configuration.
Per OAuth 2.0 and OIDC specifications:
- ID Tokens: MUST have aud = client_id(OIDC Core 1.0 spec)
- Access Tokens: Can have custom audiences (e.g., API identifiers)
Proper audience validation prevents token confusion attacks where a token intended for one API is used to access another API.
Configuration:
audience: "https://my-api.example.com"  # Your API identifier from Auth0
strictAudienceValidation: true          # Enforce strict validationResult: Fully secure, OIDC compliant with proper access token audience validation.
Configuration:
# audience not specified (defaults to client_id)
strictAudienceValidation: true  # Recommended: reject mismatched tokensBehavior: Access tokens may not contain client_id in audience, triggering security warnings. Set strictAudienceValidation: true to reject such sessions.
Configuration:
allowOpaqueTokens: true              # Enable opaque token support
requireTokenIntrospection: true      # Require introspection (recommended)Result: Secure with OAuth 2.0 Token Introspection (RFC 7662).
| Option | Purpose | Recommended Value | 
|---|---|---|
| audience | Expected audience for access tokens | Your API identifier or leave empty | 
| strictAudienceValidation | Reject sessions with audience mismatch | truefor production | 
| allowOpaqueTokens | Accept non-JWT access tokens | trueif provider issues opaque tokens | 
| requireTokenIntrospection | Force introspection for opaque tokens | truewhenallowOpaqueTokens=true | 
Production Configuration (Scenario 1):
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-auth0-secure
spec:
  plugin:
    traefikoidc:
      providerURL: https://your-auth0-domain.auth0.com
      clientID: your-auth0-client-id
      clientSecret: your-auth0-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      audience: "https://my-api.example.com"
      strictAudienceValidation: true
      allowedRolesAndGroups:
        - "https://your-app.com/roles:admin"
        - editorOpaque Token Configuration (Scenario 3):
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-auth0-opaque
spec:
  plugin:
    traefikoidc:
      providerURL: https://your-auth0-domain.auth0.com
      clientID: your-auth0-client-id
      clientSecret: your-auth0-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      allowOpaqueTokens: true
      requireTokenIntrospection: true
      strictAudienceValidation: trueFor detailed Auth0 configuration including all three scenarios, troubleshooting, and security best practices, see AUTH0_AUDIENCE_GUIDE.md.
The middleware includes comprehensive security headers support to protect your applications against common web vulnerabilities. Security headers are applied to all authenticated responses.
- Content Security Policy (CSP) - Prevents XSS and code injection
- HTTP Strict Transport Security (HSTS) - Forces HTTPS connections
- Frame Options - Protects against clickjacking attacks
- XSS Protection - Browser-level XSS filtering
- Content Type Options - Prevents MIME type sniffing
- Referrer Policy - Controls referrer information sharing
- CORS Headers - Complete Cross-Origin Resource Sharing support
- Custom Headers - Add any additional security headers
Choose from predefined security profiles or create custom configurations:
| Profile | Use Case | Security Level | CORS Enabled | 
|---|---|---|---|
| default | Standard web applications | High | Disabled | 
| strict | Maximum security applications | Very High | Disabled | 
| development | Local development | Medium | Enabled (localhost) | 
| api | API endpoints | High | Configurable | 
| custom | Custom requirements | Configurable | Configurable | 
securityHeaders:
  enabled: true
  profile: "default"securityHeaders:
  enabled: true
  profile: "strict"securityHeaders:
  enabled: true
  profile: "api"
  corsEnabled: true
  corsAllowedOrigins: 
    - "https://your-frontend.com"
    - "https://*.example.com"
  corsAllowCredentials: truesecurityHeaders:
  enabled: true
  profile: "custom"
  
  # Content Security Policy
  contentSecurityPolicy: "default-src 'self'; script-src 'self' 'unsafe-inline'"
  
  # HSTS Settings
  strictTransportSecurity: true
  strictTransportSecurityMaxAge: 31536000  # 1 year
  strictTransportSecuritySubdomains: true
  strictTransportSecurityPreload: true
  
  # Frame and Content Protection
  frameOptions: "DENY"
  contentTypeOptions: "nosniff"
  xssProtection: "1; mode=block"
  referrerPolicy: "strict-origin-when-cross-origin"
  
  # CORS Configuration
  corsEnabled: true
  corsAllowedOrigins: ["https://app.example.com"]
  corsAllowedMethods: ["GET", "POST", "PUT", "DELETE", "OPTIONS"]
  corsAllowedHeaders: ["Authorization", "Content-Type", "X-Requested-With"]
  corsAllowCredentials: true
  corsMaxAge: 86400
  
  # Custom Headers
  customHeaders:
    X-Custom-Header: "custom-value"
    X-API-Version: "v1"
  
  # Server Identification
  disableServerHeader: true
  disablePoweredByHeader: true| Parameter | Description | Default | Example | 
|---|---|---|---|
| enabled | Enable/disable security headers | true | true,false | 
| profile | Security profile to use | default | default,strict,development,api,custom | 
| contentSecurityPolicy | CSP header value | Profile-based | "default-src 'self'" | 
| strictTransportSecurity | Enable HSTS | true | true,false | 
| strictTransportSecurityMaxAge | HSTS max age in seconds | 31536000 | 86400 | 
| strictTransportSecuritySubdomains | Include subdomains in HSTS | true | true,false | 
| strictTransportSecurityPreload | Enable HSTS preload | true | true,false | 
| frameOptions | X-Frame-Options header | DENY | DENY,SAMEORIGIN,ALLOW-FROM uri | 
| contentTypeOptions | X-Content-Type-Options header | nosniff | nosniff | 
| xssProtection | X-XSS-Protection header | 1; mode=block | 1; mode=block | 
| referrerPolicy | Referrer-Policy header | strict-origin-when-cross-origin | no-referrer | 
| corsEnabled | Enable CORS headers | false | true,false | 
| corsAllowedOrigins | Allowed CORS origins | [] | ["https://app.com", "https://*.example.com"] | 
| corsAllowedMethods | Allowed CORS methods | ["GET", "POST", "OPTIONS"] | ["GET", "POST", "PUT", "DELETE"] | 
| corsAllowedHeaders | Allowed CORS headers | ["Authorization", "Content-Type"] | ["X-Custom-Header"] | 
| corsAllowCredentials | Allow credentials in CORS | false | true,false | 
| corsMaxAge | CORS preflight cache time | 86400 | 3600 | 
| customHeaders | Additional custom headers | {} | {"X-Custom": "value"} | 
| disableServerHeader | Remove Server header | true | true,false | 
| disablePoweredByHeader | Remove X-Powered-By header | true | true,false | 
| permissionsPolicy | Permissions-Policy header | `` | "geolocation=(), camera=(), microphone=()" | 
| crossOriginEmbedderPolicy | Cross-Origin-Embedder-Policy header | `` | "require-corp","credentialless","unsafe-none" | 
| crossOriginOpenerPolicy | Cross-Origin-Opener-Policy header | `` | "same-origin","same-origin-allow-popups","unsafe-none" | 
| crossOriginResourcePolicy | Cross-Origin-Resource-Policy header | `` | "same-origin","same-site","cross-origin" | 
The middleware supports flexible CORS origin patterns:
corsAllowedOrigins:
  - "https://example.com"              # Exact match
  - "https://*.example.com"            # Subdomain wildcard
  - "http://localhost:*"               # Port wildcard (development)
  - "*"                                # Allow all (not recommended)The middleware provides several advanced configuration options for production environments.
The middleware automatically optimizes for each OIDC provider:
- Google: Automatically configures access_type=offlineandprompt=consentfor refresh tokens
- Azure AD: Optimized multi-tenant support and group claim handling
- Auth0: Enhanced custom claim processing and namespace support
- Keycloak: Self-hosted deployment optimizations
- AWS Cognito: Regional endpoint handling and user pool integration
- Automatic token refresh: Proactively refreshes tokens before expiration
- Token validation: Comprehensive JWT validation with security checks
- Grace period: Configurable time window for token refresh
- Session handling: Secure session management with encrypted storage
# Optimized for high-traffic environments
rateLimit: 1000
refreshGracePeriodSeconds: 300
securityHeaders:
  enabled: true
  profile: "api"
  corsEnabled: true
  corsMaxAge: 86400# Maximum security for sensitive environments
rateLimit: 50
allowedUserDomains: ["company.com"]
allowedRolesAndGroups: ["admin", "developer"]
securityHeaders:
  enabled: true
  profile: "strict"
  corsEnabled: false# Development-friendly settings
logLevel: "debug"
forceHTTPS: false
securityHeaders:
  enabled: true
  profile: "development"
  corsEnabled: true
  corsAllowedOrigins: ["http://localhost:*"]When running multiple Traefik replicas with the OIDC plugin, you may encounter false positive replay detection errors. Each replica maintains its own in-memory JTI (JWT Token ID) cache, causing legitimate token reuse to be flagged as replay attacks.
Problem: When the same valid token hits different replicas:
- Request → Replica A → JTI added to Replica A's cache ✓
- Request → Replica B → JTI NOT in Replica B's cache ✓
- Request → Replica A → ❌ FALSE POSITIVE: "token replay detected"
Solution: Disable replay detection for distributed deployments:
disableReplayDetection: true  # Disable JTI replay detection for multi-replica setupsSecurity Note: When disableReplayDetection: true:
- ✅ Token signatures still validated
- ✅ Expiration still checked
- ✅ All other claims still verified
- ❌ JTI replay check skipped
Example Configuration:
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-multi-replica
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: your-client-id
      clientSecret: your-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      disableReplayDetection: true  # Required for multi-replica deploymentsRecommendation: For single-instance deployments, leave this setting at false (default) to maintain replay attack protection. For multi-replica deployments, set to true and consider implementing a shared cache backend (Redis/Memcached) if replay detection is required.
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-basic
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-with-open-urls
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]
      excludedURLs:
        - /login        # covers /login, /login/me, /login/reminder etc.
        - /public-data
        - /health
        - /metricsapiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-domain-restricted
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]
      allowedUserDomains:
        - company.com
        - subsidiary.comapiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-specific-users
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]
      allowedUsers:
        - user1@example.com
        - user2@another.orgapiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-domain-and-users
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]
      allowedUserDomains:
        - company.com
      allowedUsers:
        - special-user@gmail.com
        - contractor@external.orgWhen configuring access control:
- If only allowedUsersis set, only the specified email addresses will be granted access
- If only allowedUserDomainsis set, only users with email addresses from those domains will be granted access
- If both are set, access is granted if the user's email is in allowedUsersOR their email's domain is inallowedUserDomains
- If neither is set, any authenticated user will be granted access
- Email matching is case-insensitive
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-rbac
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]
      allowedRolesAndGroups:
        - admin
        - developerapiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-multi-subdomain
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      cookieDomain: .example.com  # Allows cookies to be shared across all subdomains
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]Important: The cookieDomain parameter is crucial when running behind a reverse proxy or when your application serves multiple subdomains. Without it, cookies may be created with inconsistent domains, leading to authentication issues like "CSRF token missing in session" errors.
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-custom-settings
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      logLevel: debug    # Options: debug, info, error (default: info)
      rateLimit: 500     # Requests per second (default: 100)
      forceHTTPS: false  # Default is true for security
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-custom-logout
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      postLogoutRedirectURI: /logged-out-page  # Where to redirect after logout
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-with-headers
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]
      headers:
        # Using double curly braces to escape template expressions
        - name: "X-User-Email"
          value: "{{{{.Claims.email}}}}"
        - name: "X-User-ID"
          value: "{{{{.Claims.sub}}}}"
        - name: "Authorization"
          value: "Bearer {{{{.AccessToken}}}}"
        - name: "X-User-Roles"
          value: "{{{{range $i, $e := .Claims.roles}}}}{{{{if $i}}}},{{{{end}}}}{{{{$e}}}}{{{{end}}}}"
        - name: "X-Is-Admin"
          value: "{{{{if eq .Claims.role \"admin\"}}}}true{{{{else}}}}false{{{{end}}}}"apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-with-pkce
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: 1234567890.apps.googleusercontent.com
      clientSecret: your-client-secret
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      enablePKCE: true  # Enables PKCE for added security
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-google
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://accounts.google.com
      clientID: your-google-client-id.apps.googleusercontent.com
      clientSecret: your-google-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]
        # Note: DO NOT manually add offline_access scope for Google
        # The middleware automatically handles Google-specific requirements
      refreshGracePeriodSeconds: 300  # Optional: Start refresh 5 min before expiry
      allowedUserDomains:
        - your-gsuite-domain.com  # Optional: Restrict to workspace usersapiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-azure
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://login.microsoftonline.com/your-tenant-id/v2.0
      clientID: your-azure-ad-client-id
      clientSecret: your-azure-ad-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles  # For group/role claims, configure in Azure AD Token Configuration
      allowedUserDomains:
        - yourcompany.com
      allowedRolesAndGroups:
        - "group-object-id-1"  # Azure AD group Object IDs
        - "AppRoleName"        # Application role namesapiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-auth0
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://your-auth0-domain.auth0.com
      clientID: your-auth0-client-id
      clientSecret: your-auth0-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      # Audience configuration for custom APIs
      audience: "https://my-api.example.com"  # Your API identifier from Auth0
      strictAudienceValidation: true          # Enforce proper audience validation
      scopes:
        - read:custom_data  # Custom scopes as needed
      allowedRolesAndGroups:
        - "https://your-app.com/roles:admin"  # Namespaced claims from Actions
        - editor
      postLogoutRedirectURI: /logged-out-page  # Must be in Auth0 Allowed Logout URLsNote: For detailed Auth0 audience configuration including opaque tokens and all security scenarios, see AUTH0_AUDIENCE_GUIDE.md.
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-okta
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://your-tenant.okta.com/oauth2/default
      clientID: your-okta-client-id
      clientSecret: your-okta-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - groups  # Include groups in token claims
      allowedRolesAndGroups:
        - admin
        - developer
        - "Everyone"  # Default Okta groupapiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-keycloak
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://your-keycloak-domain/auth/realms/your-realm
      clientID: your-keycloak-client-id
      clientSecret: your-keycloak-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles
        - groups
      allowedRolesAndGroups:
        - admin
        - editor
      # Ensure Keycloak client mappers add necessary claims to ID TokenapiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-cognito
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://cognito-idp.us-east-1.amazonaws.com/us-east-1_YourUserPool
      clientID: your-cognito-client-id
      clientSecret: your-cognito-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - aws.cognito.signin.user.admin  # Cognito-specific scope
      allowedRolesAndGroups:
        - admin
        - userapiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-gitlab
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://gitlab.com
      clientID: your-gitlab-client-id
      clientSecret: your-gitlab-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - read_user
        - read_api
      allowedUserDomains:
        - yourcompany.comWarning: GitHub uses OAuth 2.0, not OpenID Connect. Use only for API access, not user authentication.
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oauth-github
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: https://github.com/login/oauth
      clientID: your-github-client-id
      clientSecret: your-github-client-secret
      sessionEncryptionKey: your-secure-encryption-key-min-32-chars
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - user:email
        - read:user
      # Note: No ID tokens available, only access tokens for GitHub API
      # No refresh tokens - users must re-authenticate when tokens expireThe middleware automatically detects each provider and applies the necessary adjustments to ensure proper authentication and token refresh.
For Kubernetes environments, you can reference secrets instead of hardcoding sensitive values:
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: oidc-with-secrets
  namespace: traefik
spec:
  plugin:
    traefikoidc:
      providerURL: urn:k8s:secret:traefik-middleware-oidc:ISSUER
      clientID: urn:k8s:secret:traefik-middleware-oidc:CLIENT_ID
      clientSecret: urn:k8s:secret:traefik-middleware-oidc:SECRET
      sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
      callbackURL: /oauth2/callback
      logoutURL: /oauth2/logout
      scopes:
        - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]Don't forget to create the secret:
kubectl create secret generic traefik-middleware-oidc \
  --from-literal=ISSUER=https://accounts.google.com \
  --from-literal=CLIENT_ID=1234567890.apps.googleusercontent.com \
  --from-literal=SECRET=your-client-secret \
  -n traefikHere's a complete example of using the middleware with Docker Compose:
version: "3.7"
services:
  traefik:
    image: traefik:v3.2.1
    command:
      - "--experimental.plugins.traefikoidc.modulename=github.com/lukaszraczylo/traefikoidc"
      - "--experimental.plugins.traefikoidc.version=v0.7.10"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./traefik-config/traefik.yml:/etc/traefik/traefik.yml
      - ./traefik-config/dynamic-configuration.yml:/etc/traefik/dynamic-configuration.yml
    labels:
      - "traefik.http.routers.dash.rule=Host(`dash.localhost`)"
      - "traefik.http.routers.dash.service=api@internal"
    ports:
      - "80:80"
  hello:
    image: containous/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.hello.entrypoints=http
      - traefik.http.routers.hello.rule=Host(`hello.localhost`)
      - traefik.http.services.hello.loadbalancer.server.port=80
      - traefik.http.routers.hello.middlewares=my-plugin@file
  whoami:
    image: jwilder/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.entrypoints=http
      - traefik.http.routers.whoami.rule=Host(`whoami.localhost`)
      - traefik.http.services.whoami.loadbalancer.server.port=8000
      - traefik.http.routers.whoami.middlewares=my-plugin@filetraefik-config/traefik.yml:
log:
  level: INFO
experimental:
  localPlugins:
    traefikoidc:
      moduleName: github.com/lukaszraczylo/traefikoidc
# API and dashboard configuration
api:
  dashboard: true
  insecure: true
entryPoints:
  http:
    address: ":80"
    forwardedHeaders:
      insecure: true
providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false
  file:
    filename: /etc/traefik/dynamic-configuration.ymltraefik-config/dynamic-configuration.yml:
http:
  middlewares:
    my-plugin:
      plugin:
        traefikoidc:
          providerURL: https://accounts.google.com
          clientID: 1234567890.apps.googleusercontent.com
          clientSecret: your-client-secret
          callbackURL: /oauth2/callback
          logoutURL: /oauth2/logout
          postLogoutRedirectURI: /logged-out-page
          sessionEncryptionKey: potato-secret-is-at-least-32-bytes-long
          scopes:
            - roles  # Appended to defaults: ["openid", "profile", "email", "roles"]
          allowedUserDomains:
            - company.com
          allowedUsers:
            - special-user@gmail.com
            - contractor@external.org
          allowedRolesAndGroups:
            - admin
            - developer
          forceHTTPS: false
          logLevel: debug
          rateLimit: 100
          excludedURLs:
            - /login
            - /public
            - /health
            - /metrics
          headers:
            # Using YAML literal style to prevent Traefik from pre-evaluating templates
            - name: "X-User-Email"
              value: |
                {{.Claims.email}}
            - name: "X-User-ID"
              value: |
                {{.Claims.sub}}
            - name: "Authorization"
              value: |
                Bearer {{.AccessToken}}
            - name: "X-User-Roles"
              value: |
                {{range $i, $e := .Claims.roles}}{{if $i}},{{end}}{{$e}}{{end}}The middleware supports setting custom HTTP headers with values templated from OIDC claims and tokens. This allows you to pass authentication information to downstream services in a flexible, customized format.
Templates can access the following variables:
- {{.Claims.field}}- Access individual claims from the ID token (e.g.,- {{.Claims.email}},- {{.Claims.sub}})
- {{.AccessToken}}- The raw access token string
- {{.IdToken}}- The raw ID token string (same as AccessToken in most configurations)
- {{.RefreshToken}}- The raw refresh token string
If you encounter the error can't evaluate field AccessToken in type bool when starting Traefik, this indicates that Traefik is attempting to evaluate the template expressions before passing them to the plugin. This is a known issue when using template syntax in Traefik plugin configurations.
Solution: You must escape the template expressions using double curly braces:
headers:
  - name: "Authorization"
    value: "Bearer {{{{.AccessToken}}}}"This is the only reliable method that works consistently. Here's why:
- 
Double curly braces ( {{{{.AccessToken}}}}) ✅- The YAML parser converts {{{{→{{and}}}}→}}
- Result: Bearer {{.AccessToken}}reaches the Go template engine correctly
 
- The YAML parser converts 
- 
Other methods (YAML literal style, single quotes) do NOT work ❌ - These methods don't prevent Traefik's YAML parser from interpreting the curly braces
- The template syntax gets processed incorrectly before reaching the plugin
 
Working example configuration:
headers:
  - name: "X-User-Email"
    value: "{{{{.Claims.email}}}}"
  - name: "X-User-ID"
    value: "{{{{.Claims.sub}}}}"
  - name: "Authorization"
    value: "Bearer {{{{.AccessToken}}}}"
  - name: "X-User-Name"
    value: "{{{{.Claims.given_name}}}} {{{{.Claims.family_name}}}}"Advanced template examples:
Conditional logic:
headers:
  - name: "X-Is-Admin"
    value: "{{{{if eq .Claims.role \"admin\"}}}}true{{{{else}}}}false{{{{end}}}}"Array handling:
headers:
  - name: "X-User-Roles"
    value: "{{{{range $i, $e := .Claims.roles}}}}{{{{if $i}}}},{{{{end}}}}{{{{$e}}}}{{{{end}}}}"Notes:
- Variable names are case-sensitive (use .Claims, not.claims)
- Missing claims will result in <no value>in the header value
- The middleware validates templates during startup and logs errors for invalid templates
- Always use double curly braces ({{{{and}}}}) to escape template expressions in YAML configuration files
When a user is authenticated, the middleware sets the following headers for downstream services:
- X-Forwarded-User: The user's email address
- X-User-Groups: Comma-separated list of user groups (if available)
- X-User-Roles: Comma-separated list of user roles (if available)
- X-Auth-Request-Redirect: The original request URI
- X-Auth-Request-User: The user's email address
- X-Auth-Request-Token: The user's access token
The middleware also sets the following security headers:
- X-Frame-Options: DENY
- X-Content-Type-Options: nosniff
- X-XSS-Protection: 1; mode=block
- Referrer-Policy: strict-origin-when-cross-origin
Important: ID Token Validation
This Traefik OIDC plugin performs authentication and extracts user claims (like email, roles, groups) exclusively from the ID Token provided by your OIDC provider. It does not primarily use the Access Token for these critical functions. Therefore, it is crucial to ensure that all necessary claims are included in the ID Token itself. A common issue is that some OIDC providers might, by default, place certain claims only in the Access Token or UserInfo endpoint.
This section provides guidance on configuring popular OIDC providers to work optimally with this plugin.
Google's OIDC implementation is well-supported with automatic configuration.
- Automatic Configuration: The middleware automatically detects Google and applies required settings:
- Uses access_type=offlineandprompt=consentfor refresh tokens
- Filters out unsupported offline_accessscope
- Handles Google-specific token refresh
 
- Uses 
- Setup Requirements:
- Create OAuth 2.0 credentials in Google Cloud Console
- Configure OAuth consent screen (must be "Published" for production)
- Add authorized redirect URIs
 
- ID Token Claims: Google includes standard claims like email,sub,name,given_name,family_name,picture
- Hosted Domain: For Google Workspace, the hdclaim contains the organization domain
- Best Practices: Use providerURL: https://accounts.google.com
Azure AD provides comprehensive enterprise OIDC support.
- Tenant Configuration: Use tenant-specific endpoint: https://login.microsoftonline.com/{tenant-id}/v2.0
- Group Claims: Configure in App Registration → Token Configuration → Add groups claim
- ID Token Claims: Includes email,name,preferred_username,oidby default
- Group Handling: Be aware of group "overage" - too many groups results in a groups claim link instead of embedded groups
- Optional Claims: Add custom claims via Token Configuration section
- Multi-tenant: Supports both single-tenant and multi-tenant applications
Auth0 provides flexible OIDC with custom claims support.
- Custom Claims: Use Auth0 Actions (recommended) or Rules to add claims to ID Token:
// Auth0 Action example exports.onExecutePostLogin = async (event, api) => { const namespace = 'https://your-app.com/'; if (event.authorization) { api.idToken.setCustomClaim(namespace + 'roles', event.authorization.roles); api.idToken.setCustomClaim('email', event.user.email); } }; 
- Logout Configuration: Ensure postLogoutRedirectURIis in "Allowed Logout URLs"
- Application Type: Set to "Regular Web Application" for server-side flows
- Refresh Tokens: Automatically handled with offline_accessscope
Okta provides enterprise-grade OIDC with extensive customization.
- Application Setup: Create OIDC Web Application in Okta Admin Console
- Authorization Server: Use default (/oauth2/default) or custom authorization server
- Group Claims: Configure Groups claim in authorization server to include user groups
- Scopes: Default scopes sufficient; add groupsscope for group information
- Sign-On Policy: Configure authentication policies and MFA requirements
- Custom Claims: Add custom attributes via user profiles and authorization server claims
Keycloak is highly configurable, requiring proper client mapper setup.
- Client Mappers: Essential for including claims in ID Token:
- Email: User Property mapper for emailwith "Add to ID token" enabled
- Roles: User Client Role or User Realm Role mappers with "Add to ID token" enabled
- Groups: Group Membership mapper with "Add to ID token" enabled
 
- Email: User Property mapper for 
- Token Claim Names: Use mapper "Token Claim Name" in allowedRolesAndGroupsconfiguration
- Realm Configuration: Ensure proper realm settings and client configuration
- Issuer URL Format: https://your-keycloak/auth/realms/your-realm
- Troubleshooting: Verify mappers in Clients → Your Client → Mappers tab
AWS Cognito provides managed OIDC with regional deployment.
- User Pool Setup: Create User Pool with proper app client configuration
- App Client: Enable "Authorization code grant" and configure callback URLs
- Regional Endpoints: Auto-detected from issuer URL format
- Custom Attributes: Configure custom attributes and map to claims
- Groups: Use Cognito Groups for role-based access control
- Federation: Supports federated identity providers (SAML, social providers)
GitLab supports OIDC for both GitLab.com and self-hosted instances.
- Application Registration: Create in GitLab Admin Area → Applications
- Scopes: Use openid,profile,emailfor basic claims
- Self-hosted: Use your GitLab instance URL as providerURL
- GitLab.com: Use https://gitlab.comasproviderURL
- Group Claims: May require custom configuration for group information
- API Access: Include read_apiscope for GitLab API access via access token
Important: GitHub uses OAuth 2.0, not OpenID Connect.
- OAuth App Setup: Register OAuth App in GitHub Settings → Developer settings
- Limitations:
- No ID tokens (access tokens only)
- No refresh tokens (tokens expire, requiring re-authentication)
- No standard OIDC claims
 
- Use Cases: API access only, not suitable for user authentication with claims
- Scopes: Use user:email,read:userfor basic profile access
- Detection: Auto-detected from github.comin issuer URL
Auth0 is generally OIDC compliant and works well.
- ID Token Claims:
- To add custom claims or standard claims not included by default (like roles or permissions) to the ID Token, you'll need to use Auth0 Rules or Actions.
- Using Actions (Recommended): Create a custom Action that runs after login to add claims to the ID Token. Example:
// Auth0 Action to add email and roles to ID Token exports.onExecutePostLogin = async (event, api) => { const namespace = 'https://your-app.com/'; // Or your custom namespace if (event.authorization) { api.idToken.setCustomClaim(namespace + 'roles', event.authorization.roles); api.idToken.setCustomClaim('email', event.user.email); // Standard claim, ensure it's there // Add other claims as needed } }; 
- Ensure the claims you add (e.g., https://your-app.com/roles) are then used in the plugin'sallowedRolesAndGroupsorheadersconfiguration.
 
- Scopes: Request appropriate scopes. You might need custom scopes if your Actions/Rules depend on them to add specific claims.
- Endpoints: Your providerURLwill behttps://your-auth0-domain.auth0.com.
- Logout: Ensure postLogoutRedirectURIis registered in your Auth0 application settings under "Allowed Logout URLs".
For other OIDC providers (e.g., Okta, Zitadel, self-hosted solutions):
- ID Token is Key: The primary requirement is that all claims needed for authentication decisions (email, roles, groups, custom attributes for headers) must be included in the ID Token.
- Check Provider Documentation: Consult your OIDC provider's documentation on how to:
- Configure client applications.
- Map user attributes, roles, or group memberships to claims in the ID Token.
- Define custom scopes if they are necessary to include certain claims.
 
- Standard Endpoints: Ensure your provider exposes a standard OIDC discovery document (.well-known/openid-configuration) at theproviderURL. The plugin uses this to find authorization, token, JWKS, and end_session endpoints.
- Scopes: Always include openidin your scopes.profileandemailare generally recommended. Add other scopes as required by your provider to release specific claims to the ID Token.
- Troubleshooting: If the plugin isn't working as expected (e.g., access denied, claims missing), the first step is to decode the ID Token received from your provider (e.g., using jwt.io) to verify its contents. This will show you exactly what claims the plugin is seeing.
For common issues and general troubleshooting, please refer to the Troubleshooting section.
Set the logLevel to debug to get more detailed logs:
logLevel: debug- Token verification failed: Check that your providerURLis correct and accessible.
- Session encryption key too short: Ensure your sessionEncryptionKeyis at least 32 bytes long.
- No matching public key found: The JWKS endpoint might be unavailable or the token's key ID (kid) doesn't match any key in the JWKS.
- Access denied: Your email domain is not allowed: The user's email domain is not in the allowedUserDomainslist.
- Access denied: You do not have any of the allowed roles or groups: The user doesn't have any of the roles or groups specified in allowedRolesAndGroups.
- "can't evaluate field AccessToken in type bool" error: This error occurs when Traefik attempts to evaluate template expressions in the headers configuration before passing them to the plugin. To fix this:
- Use double curly braces to escape template expressions: value: "Bearer {{{{.AccessToken}}}}"
- This is the only reliable method that works with Traefik's YAML parsing
- See the Templated Headers section for complete examples
 
- Use double curly braces to escape template expressions: 
- 
Google sessions expire after ~1 hour: If using Google as the OIDC provider and sessions expire prematurely: - Do NOT manually add the offline_accessscope. Google rejects this scope as invalid.
- The middleware automatically applies Google parameters (access_type=offlineandprompt=consent).
- Ensure your Google Cloud OAuth consent screen is "Published" for production.
- "Testing" mode limits refresh token validity.
 
- Do NOT manually add the 
- 
Keycloak: Claims Missing from ID Token: - Configure client mappers to add email, roles, groups to ID Token
- Check "Add to ID token" is enabled for all required mappers
- Verify "Token Claim Name" matches your configuration
 
- 
Azure AD: Group overage issues: - Users with many groups may receive a groups link instead of embedded groups
- Consider using app roles instead of groups for many-group scenarios
- Configure group claims in App Registration → Token Configuration
 
- 
Auth0: Custom claims not appearing: - Use Auth0 Actions (not Rules) to add custom claims to ID Token
- Ensure namespaced claims follow format: https://your-app.com/claim
- Add claims to ID token specifically, not just access token
 
- 
Okta: Authorization server issues: - Verify using correct authorization server endpoint (/oauth2/defaultor custom)
- Ensure Groups claim is configured in authorization server
- Check application assignment and user group membership
 
- Verify using correct authorization server endpoint (
- 
AWS Cognito: Regional endpoint errors: - Use correct regional endpoint format: cognito-idp.{region}.amazonaws.com
- Verify User Pool ID is correct in issuer URL
- Check app client has authorization code grant enabled
 
- Use correct regional endpoint format: 
- 
GitLab: Self-hosted instance issues: - Ensure issuer URL points to your GitLab instance root
- Verify application is created in Admin Area → Applications
- Check redirect URI configuration matches exactly
 
- 
GitHub: Limited functionality warnings: - Remember GitHub is OAuth 2.0 only, not OIDC
- No ID tokens available (access tokens only)
- No refresh tokens (re-authentication required on expiry)
- Use only for GitHub API access, not user authentication
 
The middleware includes built-in warnings for provider-specific limitations. Check your logs for important notices about:
- GitHub OAuth 2.0 limitations (no OIDC support)
- Auth0 offline_access scope requirements
- Keycloak URL pattern requirements
- AWS Cognito regional endpoint requirements
- Provider-specific setup recommendations
For detailed provider-specific guidance, see the Provider-Specific Configuration Examples section.
- Security Headers: Complete security headers system with CSP, HSTS, CORS, and XSS protection
- Multiple Security Profiles: Choose from default, strict, development, API, or custom security configurations
- Enhanced Token Validation: Improved JWT validation with comprehensive security checks
- Advanced Rate Limiting: Configurable rate limiting to prevent abuse
- Automatic Provider Detection: Seamless configuration for major OIDC providers
- Improved Error Handling: Better error messages and graceful degradation
- Enhanced Session Management: More reliable session handling with automatic cleanup
- Flexible Configuration: Expanded configuration options for different deployment scenarios
- Automatic Token Refresh: Proactive token refresh to prevent authentication interruptions
- Memory Management: Improved memory efficiency and automatic resource cleanup
- Better Provider Support: Enhanced compatibility with provider-specific features
- Comprehensive Testing: Extensive test coverage ensures reliability in production
The middleware is designed with the following principles:
- Reliability: Automatic error recovery and graceful degradation
- Security: Comprehensive security measures and validation
- Performance: Efficient resource usage and caching
- Flexibility: Extensive configuration options for different use cases
- Compatibility: Support for all major OIDC providers with automatic detection
- Automatic Session Management: Handles session lifecycle, cleanup, and security
- Provider Integration: Seamless integration with OIDC providers including auto-discovery
- Security Integration: Built-in security headers and protection mechanisms
- Resource Management: Efficient memory usage and automatic cleanup
- Error Handling: Comprehensive error recovery and user-friendly error messages
Contributions are welcome! Please feel free to submit a Pull Request.
- Memory Management: Ensure all goroutines can be cancelled and resources are bounded
- Testing: Add tests for new features, including memory leak tests where appropriate
- Race Conditions: Run tests with -raceflag to detect race conditions
- Documentation: Update README and .traefik.yml for any new configuration options