Authentication Security: 2FA, Token Methods, Scopes & Claims

Dynamic authorization flows, custom client authenticators, and standard OIDC scope configuration

1. Dynamic 2FA Rules Engine

Zero IDS evaluates policies dynamically based on the requesting client's settings and individual user profile configurations.

Evaluating Authorization Policy

The server performs policy checks during authorization initiation:

Organization-enforced 2FA: If the client organization mandates multi-factor authentication (auth_mode: "password_and_otp"), the server prompts the user for 2FA, even if 2FA is disabled in the user's profile settings.
Flexible 2FA: If client organization enforces auth_mode: "flexible", a user with 2FA enabled in their profile settings is prompted for 2FA. If a user has 2FA disabled, they authenticate directly with their primary credentials.

Evaluation Matrix

Client Auth Mode	User 2FA Preferences	Attempted Flow	Dynamic Outcome
password_and_otp (Enforced)	Enabled	Password / Magic Link	2FA Promoted (OTP via Email/SMS)
password_and_otp (Enforced)	Disabled	Password / Magic Link	2FA Promoted (Enforced Onboarding)
flexible (User Choice)	Enabled	Password / Magic Link	2FA Promoted (User Preference)
flexible (User Choice)	Disabled	Password / Magic Link	Authenticated Successfully (Direct)
otp (OTP Only)	Disabled / Enabled	OTP Flow	Authenticated Successfully (Direct)

2. Token Endpoint Authentication Methods

Specify how client applications authenticate with the /oidc/token endpoint when exchanging authorization codes:

A. client_secret_basic (Default)

Client credentials sent inside the standard HTTP Basic Auth header. The header values are base64 encoded as Authorization: Basic BASE64(client_id:client_secret):

// Header format:
// Authorization: Basic c2Fhcy1jbGllbnQtaWQ6c3VwZXItc2VjcmV0LWtleQ==

// Node.js openid-client config:
const client = new issuer.Client({
    client_id: 'saas-client-id',
    client_secret: 'super-secret-key',
    token_endpoint_auth_method: 'client_secret_basic' // Default
});

B. client_secret_post

Client credentials sent as POST body parameters:

// POST body format:
// POST /oidc/token
// Content-Type: application/x-www-form-urlencoded
// grant_type=authorization_code&code=xyz&client_id=saas-client-id&client_secret=super-secret-key

C. none (Public Clients)

For public client applications (SPAs, mobile apps) where client secrets are omitted. PKCE parameters are evaluated for verification:

// POST /oidc/token
// grant_type=authorization_code&code=xyz&client_id=spa-client-id&code_verifier=high-entropy-random-string

3. Scopes & Claims Configuration

Scopes map to standard claim profiles returned inside the ID token or via userinfo endpoint queries:

Scopes Map

Scope Name	Included Claims	Purpose
`openid`	`iss, sub, aud, exp, iat`	Identifies request as OIDC; returns core ID Token
`profile`	`firstName, lastName, name, preferred_username`	Returns user profile details
`email`	`email, email_verified`	Returns verified email credentials
`phone`	`phone_number, phone_number_verified`	Returns verified phone details for SMS/OTP