traefik plugin 0.7.7 (#73)

* Automatic discovery of the scopes. Issue #61 raised very valid concerns about users configuring scopes that are not supported by the provider. This change introduces automatic discovery of supported scopes by fetching the provider's discovery document and filtering out unsupported scopes. Before: User configures: scopes: ["openid", "profile", "email", "offline_access"] Self-hosted GitLab: "The requested scope is invalid, unknown, or malformed" Authentication: ❌ FAILS After: User configures: scopes: ["openid", "profile", "email", "offline_access"] Middleware checks discovery doc → offline_access not supported Automatically filters to: ["openid", "profile", "email"] Authentication: ✅ SUCCEEDS * Resolves issue #74 by enabling user to specify expected audience in the configuration. * Fix flaky tests.
2026-06-05 22:44:17 +00:00 · 2025-10-08 11:44:00 +01:00
parent 79d34ea4c9
commit bde1db1c3b
29 changed files with 3214 additions and 85 deletions
@@ -89,8 +89,9 @@ scopes: ["openid", "profile", "email", "offline_access"]
 - **Offline access**: Requires `offline_access` scope for refresh tokens
 - **Access token validation**: Supports both JWT and opaque access tokens
 - **Tenant isolation**: Can restrict to specific Azure AD tenants
+- **Application ID URI**: Supports custom audience for protected APIs

-### Example Configuration
+### Example Configuration (Basic)
 ```yaml
 http:
  middlewares:
@@ -108,6 +109,33 @@ http:
          forceHttps: true
 ```

+### Azure AD API Configuration (Application ID URI)
+
+When exposing your application as an API with a custom Application ID URI, you need to specify the `audience` parameter. Azure AD includes the Application ID URI in the JWT `aud` claim.
+
+```yaml
+http:
+  middlewares:
+    azure-api-oidc:
+      plugin:
+        traefik-oidc:
+          providerUrl: "https://login.microsoftonline.com/common/v2.0"
+          clientId: "12345678-1234-1234-1234-123456789abc"
+          clientSecret: "your-azure-client-secret"
+          # Specify the Application ID URI as audience
+          audience: "api://12345678-1234-1234-1234-123456789abc"
+          callbackUrl: "https://app.example.com/auth/callback"
+          logoutUrl: "https://app.example.com/auth/logout"
+          scopes: ["openid", "profile", "email", "offline_access"]
+          forceHttps: true
+```
+
+**Important**:
+- The `audience` parameter should match your Application ID URI (typically `api://{app-id}`)
+- Find your Application ID URI in Azure Portal → App Registration → Expose an API → Application ID URI
+- Without the `audience` parameter, access tokens with custom audiences will be rejected
+- For ID token validation only (no API access), you can omit the `audience` parameter
+
 ### Azure App Registration Setup
 1. Go to [Azure Portal](https://portal.azure.com/)
 2. Navigate to "Azure Active Directory" > "App registrations"
@@ -116,6 +144,12 @@ http:
 5. Create client secret in "Certificates & secrets"
 6. Configure API permissions for required scopes

+### Azure AD API Exposure Setup (for custom audiences)
+1. In your App Registration, go to "Expose an API"
+2. Set the Application ID URI (e.g., `api://12345678-1234-1234-1234-123456789abc`)
+3. Add any custom scopes your API exposes
+4. Update the middleware configuration to include the `audience` parameter with this URI
+
 ---

 ## Auth0
@@ -138,8 +172,9 @@ scopes: ["openid", "profile", "email", "offline_access"]
 - **Rules and hooks**: Leverages Auth0's extensibility
 - **Social connections**: Works with Auth0's social identity providers
 - **Offline access**: Requires `offline_access` scope
+- **API audiences**: Supports custom audience for API access tokens

-### Example Configuration
+### Example Configuration (Basic)
 ```yaml
 http:
  middlewares:
@@ -158,6 +193,34 @@ http:
          enablePkce: true
 ```

+### Auth0 API Configuration (Custom Audience)
+
+When using Auth0 APIs with custom audience parameters, you need to specify the `audience` field. Auth0 includes the API identifier in the JWT `aud` claim instead of the `clientId`.
+
+```yaml
+http:
+  middlewares:
+    auth0-api-oidc:
+      plugin:
+        traefik-oidc:
+          providerUrl: "https://company.auth0.com"
+          clientId: "abcdef123456789"
+          clientSecret: "your-auth0-client-secret"
+          # Specify the Auth0 API identifier as audience
+          audience: "https://api.company.com"
+          callbackUrl: "https://app.example.com/auth/callback"
+          logoutUrl: "https://app.example.com/auth/logout"
+          scopes: ["openid", "profile", "email", "offline_access"]
+          forceHttps: true
+          enablePkce: true
+```
+
+**Important**:
+- The `audience` parameter should match your Auth0 API identifier (not the client ID)
+- Find your API identifier in Auth0 Dashboard → APIs → Your API → Settings → Identifier
+- Without the `audience` parameter, access tokens with custom audiences will be rejected with "invalid audience" error
+- For ID token validation only (no APIs), you can omit the `audience` parameter
+
 ### Auth0 Application Setup
 1. Go to [Auth0 Dashboard](https://manage.auth0.com/)
 2. Create new application (Regular Web Application)
@@ -165,6 +228,14 @@ http:
 4. Configure allowed logout URLs: `https://your-domain.com/auth/logout`
 5. Enable OIDC Conformant in Advanced Settings

+### Auth0 API Setup (for custom audiences)
+1. Go to Auth0 Dashboard → APIs
+2. Create a new API or select existing API
+3. Note the "Identifier" field (e.g., `https://api.company.com`) - this is your `audience` value
+4. In API Settings → Machine to Machine Applications, authorize your application
+5. Configure API permissions/scopes as needed
+6. Use the API identifier as the `audience` parameter in your configuration
+
 ---

 ## GitHub
@@ -236,7 +307,7 @@ scopes: ["openid", "profile", "email"]
 - **Self-hosted support**: Works with self-hosted GitLab instances
 - **Group membership**: Can restrict by GitLab groups
 - **Project access**: Can validate project permissions
- **Offline access**: Supports refresh tokens with `offline_access`
+- **Offline access**: Supports refresh tokens without requiring `offline_access` scope

 ### Example Configuration
 ```yaml
@@ -250,7 +321,9 @@ http:
          clientSecret: "your-gitlab-application-secret"
          callbackUrl: "https://app.example.com/auth/callback"
          logoutUrl: "https://app.example.com/auth/logout"
-          scopes: ["openid", "profile", "email", "offline_access"]
+          scopes: ["openid", "profile", "email"]
+          # Note: GitLab doesn't support the offline_access scope.
+          # Refresh tokens are issued automatically for the openid scope.
          allowedRolesAndGroups: ["developers", "maintainers"]
          forceHttps: true
          enablePkce: true
@@ -459,8 +532,120 @@ http:

 ---

+## Automatic Scope Filtering
+
+### Overview
+
+The middleware automatically filters OAuth scopes based on the provider's capabilities declared in their OIDC discovery document (`.well-known/openid-configuration`). This prevents authentication failures when providers reject unsupported scopes.
+
+### How It Works
+
+1. **Discovery Document Parsing**: The middleware fetches the provider's discovery document and extracts the `scopes_supported` field
+2. **Intelligent Filtering**: Requested scopes are filtered to only include those the provider supports
+3. **Fallback Behavior**: If the provider doesn't declare `scopes_supported`, all requested scopes are used (backward compatible)
+4. **Provider-Specific Handling**: Special logic for Google and Azure is preserved and applied after filtering
+
+### Example Scenarios
+
+#### Self-Hosted GitLab
+
+**Problem**: Self-hosted GitLab instances reject the `offline_access` scope with error:
+```
+The requested scope is invalid, unknown, or malformed.
+```
+
+**Solution**: The middleware automatically detects this by:
+1. Reading GitLab's discovery document at `https://gitlab.example.com/.well-known/openid-configuration`
+2. Observing that `offline_access` is NOT in the `scopes_supported` list
+3. Filtering out `offline_access` from the request
+4. Authentication succeeds
+
+**Configuration**:
+```yaml
+http:
+  middlewares:
+    gitlab-oidc:
+      plugin:
+        traefik-oidc:
+          providerUrl: "https://gitlab.example.com"
+          clientId: "your-gitlab-application-id"
+          clientSecret: "your-gitlab-application-secret"
+          callbackUrl: "https://app.example.com/auth/callback"
+          scopes: ["openid", "profile", "email", "offline_access"]
+          # Even though offline_access is listed, it will be automatically
+          # filtered out if GitLab doesn't support it
+```
+
+#### Auth0 or Keycloak
+
+These providers typically support `offline_access` and it will be included:
+
+```yaml
+# Auth0 scopes_supported: ["openid", "profile", "email", "offline_access", ...]
+# Result: All requested scopes are sent
+```
+
+### Benefits
+
+1. **Self-Hosted Support**: Works seamlessly with self-hosted provider instances
+2. **No Manual Configuration**: No need to know which scopes each provider supports
+3. **Error Prevention**: Eliminates "invalid scope" authentication failures
+4. **Standards Compliant**: Uses official OIDC discovery specification (RFC 8414)
+5. **Backward Compatible**: Existing configurations continue to work
+
+### Logging
+
+The middleware provides detailed logging for scope filtering:
+
+```
+INFO: ScopeFilter: Filtered unsupported scopes for https://gitlab.example.com: [offline_access]
+DEBUG: ScopeFilter: Provider https://gitlab.example.com supported scopes: [openid profile email read_user read_api]
+DEBUG: ScopeFilter: Final filtered scopes: [openid profile email]
+```
+
+### Troubleshooting
+
+**Issue**: Provider rejects scope even after filtering
+
+**Possible Causes**:
+1. Provider's discovery document is outdated
+2. Provider doesn't properly implement `scopes_supported`
+3. Custom authorization server with non-standard behavior
+
+**Solutions**:
+1. Use `overrideScopes: true` and explicitly list only supported scopes
+2. Check the provider's discovery document manually: `curl https://your-provider/.well-known/openid-configuration`
+3. Review middleware debug logs for filtering decisions
+
+---
+
 ## Common Configuration Options

+### Audience Configuration
+
+The `audience` parameter specifies the expected JWT audience claim value. This is particularly important when using Auth0 APIs, Azure AD Application ID URIs, or other providers with custom audience requirements.
+
+```yaml
+# Optional: Custom audience for JWT validation
+# If not set, defaults to clientID for backward compatibility
+audience: "https://api.example.com"  # Auth0 API identifier
+# OR
+audience: "api://12345-guid"  # Azure AD Application ID URI
+```
+
+**When to use**:
+- **Auth0**: When using Auth0 APIs with custom audience parameters
+- **Azure AD**: When exposing your app as an API with Application ID URI
+- **Keycloak**: When using audience-restricted tokens
+- **Okta**: When using custom authorization servers with API audiences
+
+**When to omit**:
+- For standard ID token validation (default behavior)
+- When the provider sets `aud` claim to your `clientID`
+- For backward compatibility with existing configurations
+
+**Security Note**: The `audience` parameter prevents token confusion attacks by ensuring tokens issued for one service cannot be used at another service.
+
 ### Security Settings
 ```yaml
 # Force HTTPS (recommended for production)