Advanced OAuth2 Settings
Auris supports four advanced OAuth2 capabilities beyond the standard Authorization Code + PKCE flow: Device Authorization Flow, Client-Initiated Backchannel Authentication (CIBA), DPoP (Demonstration of Proof-of-Possession), and Token Exchange. Each feature is configured per-application and can be enabled independently.
These features address enterprise scenarios such as authenticating on input-constrained devices (smart TVs, CLI tools), server-initiated authentication (call centers, kiosk approvals), cryptographic sender-constraining of tokens, and controlled identity delegation.
Access via Console → Applications → select an application → Settings tab.
Device Authorization Flow (RFC 8628)
The Device Authorization Flow allows users to authenticate on devices that lack a browser or have limited input capabilities. The device displays a short code that the user enters on a separate device (phone or computer) to authorize the session.
Enabling Device Flow
Open the application settings
Go to Console → Applications and click on the application you want to configure. Navigate to the Settings tab.
Enable Device Flow
Toggle Enable Device Flow to on.
Configure settings
| Setting | Default | Description |
|---|---|---|
| Polling Interval | 5 seconds | How often the device should poll the token endpoint for authorization status. Setting this too low increases server load. |
| Code Lifetime | 600 seconds (10 min) | How long the user code remains valid. After expiry, the device must request a new code. |
| User Code Length | 8 characters | Length of the code shown to the user. Longer codes are more secure but harder to type. |
Save
Click Save to apply the configuration.
Verification URI
After enabling Device Flow, Auris provides a Verification URI for your application. This is the URL you display to users alongside the device code. The format is:
https://auth.yourdomain.com/hosted/deviceYour device application should display both the verification URI and the user code, for example:
To sign in, visit: https://auth.yourdomain.com/hosted/device
Enter code: ABCD-EFGHThe verification URI is the same for all applications in your tenant. The user code uniquely identifies the device authorization session, so no application-specific URL is needed.
How It Works
- The device requests a device code from
POST /api/oauth/device/authorize - The user visits the verification URI and enters the code
- The user authenticates normally (password, MFA, SSO — whatever your tenant requires)
- The device polls
POST /api/auth/tokenwithgrant_type=urn:ietf:params:oauth:grant-type:device_codeuntil the user completes authentication - Once authorized, the device receives access and refresh tokens
/api/oauth/device/authorize/api/auth/tokenClient-Initiated Backchannel Authentication (CIBA)
CIBA enables server-to-server authentication where the relying party initiates authentication without the user being present at the application. The user receives a notification (SMS or email) and approves the login on their own device.
Typical use cases include call-center authentication (“we’ve sent a notification to your phone — please approve it to verify your identity”) and background re-authentication for long-running sessions.
Enabling CIBA
Open the application settings
Go to Console → Applications and select the application. Navigate to the Settings tab.
Enable CIBA
Toggle Enable CIBA to on.
Configure notification settings
| Setting | Default | Description |
|---|---|---|
| Notification Mode | Poll | How the relying party receives the authentication result. See Notification Modes below. |
| Notification Channel | How the user is notified of the pending authentication: SMS or Email. | |
| Request Lifetime | 300 seconds (5 min) | How long the authentication request is valid before expiring. |
| Token Delivery Mode | Poll | How the client receives the final tokens. Options: poll, ping, push. |
Configure callback URL (ping/push modes only)
If using ping or push notification mode, enter the Callback URL where Auris should send the authentication result.
Save
Click Save to apply the configuration.
Notification Modes
| Mode | Behavior |
|---|---|
| Poll | The relying party polls the token endpoint at intervals until the user responds. Simplest to implement. |
| Ping | Auris sends a notification to the callback URL when the user responds, then the relying party calls the token endpoint to retrieve tokens. |
| Push | Auris sends the tokens directly to the callback URL when the user approves. The relying party does not need to poll. |
Push mode delivers tokens directly to your callback URL. Ensure this endpoint is secured with TLS and validates the incoming request signature. If the callback URL is compromised, an attacker could intercept tokens.
/api/oauth/ciba/authorizeDPoP (Demonstration of Proof-of-Possession) — RFC 9449
DPoP binds access tokens to a specific client by requiring the client to prove possession of a private key on every request. This prevents token theft and replay attacks — even if an access token is intercepted, it cannot be used without the corresponding private key.
Enabling DPoP
Open the application settings
Navigate to Console → Applications → select the application → Settings tab.
Enable DPoP
Toggle Enable DPoP to on.
Configure DPoP settings
| Setting | Default | Description |
|---|---|---|
| Enable DPoP | Off | Allows clients to use DPoP proofs when requesting tokens. |
| Require DPoP | Off | When enabled, Auris rejects token requests that do not include a valid DPoP proof. Only enable this after confirming all clients support DPoP. |
| Require Nonces | Off | Adds server-issued nonces to the DPoP flow for replay protection. Increases security but adds an extra round-trip. |
Save
Click Save to apply.
How DPoP Works
- The client generates an asymmetric key pair (typically ECDSA P-256)
- On each token request, the client creates a DPoP proof JWT signed with its private key, containing the HTTP method, URL, and a unique identifier
- Auris verifies the proof and binds the issued token to the client’s public key (JWK thumbprint)
- On subsequent API calls, the client includes both the access token and a fresh DPoP proof header
- Resource servers verify that the token’s
jkt(JWK Thumbprint) claim matches the DPoP proof
DPoP configuration also appears on the application detail page under the Security section, providing quick access to the same settings from multiple navigation paths.
Token Exchange (RFC 8693)
Token Exchange allows one service to exchange an access token for a new token with different scopes, subject, or audience. This supports two patterns: impersonation (acting as another user) and delegation (acting on behalf of another user while retaining the original identity).
Enabling Token Exchange
Open the application settings
Navigate to Console → Applications → select the application → Settings tab.
Enable Token Exchange
Toggle Enable Token Exchange to on.
Select allowed exchange types
| Type | Permission Required | Description |
|---|---|---|
| Impersonation | impersonate:users | The resulting token has the target user as its subject. The original identity is not preserved. Used for admin support scenarios. |
| Delegation | delegate:tokens | The resulting token includes an act (actor) claim preserving the original caller’s identity. The subject is the target user. Used for service-to-service delegation chains. |
Save
Click Save to apply.
Impersonation is a powerful capability. Only grant the impersonate:users
permission to highly trusted applications and roles. All token exchanges are logged in the audit log
with the original and target identities.
/api/auth/tokenMonitoring
The Console provides dedicated monitoring pages for each advanced OAuth2 feature. Access them from the Advanced OAuth section in the sidebar.
Device Codes
Go to Console → Advanced OAuth → Device Codes to view all active and expired device authorization sessions.
| Column | Description |
|---|---|
| User Code | The code displayed to the user |
| Client | The application that requested the device code |
| Status | Pending, Authorized, Expired, or Denied |
| Created At | When the device code was issued |
| Expires At | When the device code expires |
| User | The user who authorized the session (if authorized) |
CIBA Requests
Go to Console → Advanced OAuth → CIBA Requests to view backchannel authentication requests.
| Column | Description |
|---|---|
| Request ID | Unique identifier for the CIBA request |
| User | The user being authenticated |
| Client | The application that initiated the request |
| Status | Pending, Completed, Expired, or Denied |
| Notification Mode | Poll, Ping, or Push |
| Created At | When the request was initiated |
Token Exchanges
Go to Console → Advanced OAuth → Token Exchanges to view the audit log of all token exchange operations.
| Column | Description |
|---|---|
| Timestamp | When the exchange occurred |
| Type | Impersonation or Delegation |
| From Identity | The original authenticated identity |
| To Identity | The target user identity |
| Client | The application that performed the exchange |
| Scopes | The scopes granted on the exchanged token |
Risk Scoring
Advanced OAuth2 features integrate with the Auris risk scoring engine. When risk scoring is enabled, each authentication through Device Flow, CIBA, or Token Exchange is evaluated for risk just like a standard login. High-risk authentications may trigger step-up MFA requirements.
For detailed configuration of the risk engine, factor weights, thresholds, and custom rules, see the dedicated Risk Scoring & Adaptive MFA page.
Permissions
The following permissions control access to advanced OAuth2 features:
| Permission | Description |
|---|---|
view:device_codes | View active device authorization sessions |
manage:device_codes | Revoke device codes |
view:token_exchanges | View token exchange audit log |
impersonate:users | Perform impersonation token exchanges |
delegate:tokens | Perform delegation token exchanges |
manage:dpop_config | Configure DPoP settings on applications |
view:ciba_requests | View backchannel authentication requests |
manage:ciba_config | Configure CIBA settings on applications |
view:risk_assessments | View risk assessment data |
manage:risk_rules | Create and modify risk scoring rules |
manage:advanced_oauth | Full access to all advanced OAuth2 settings |
Related Guides
- Risk Scoring & Adaptive MFA — Configure the risk engine that protects all OAuth2 flows
- Device Authorization Flow — Developer guide for implementing Device Flow in your application
- CIBA Integration — Developer guide for backchannel authentication
- DPoP for Token Security — How to implement DPoP in your client application
- Token Exchange — Developer guide for impersonation and delegation
- Applications — Managing application settings in the Console