OAuth2 Interactive Testing Interface

Test OAuth2 flows and explore authentication server functionality in real-time. This interface allows you to experiment with different grant types, validate configurations, and understand the authentication process.

🏠 Server Navigation

Quick access to server resources

🏠 Server Home

🔧 Configuration

⚙️Environment Detection & Setup

🌐 Environment Detection

Detected Environment: Detecting...

Server URL: Loading...

Connection Status: Checking...

Server Version: Unknown

Environment Override

Note: Production and Development environments require configuration. Use Custom environment to set your server URLs.

📋 Client Configuration

Client ID:

Client Secret (confidential clients only): Leave empty for public clients using PKCE

Redirect URI: Will be automatically set to current page with flow-testing anchor

🎯 Scope Selection

Select the permissions your application needs:

Personal User Data

Account Actions

General Entities

Urban Water

WCM

WCM Importer

Consumption Recorder

System & Administrative

❌ Invalid Scopes (for Error Testing)

Note: These scopes are intentionally invalid and will cause errors. Use them to test error handling in your OAuth2 implementation.

Selected Scopes:

🚀 OAuth2 Flow Testing

🔐Authorization Code Flow (Standard)

Best for web applications with a backend server that can securely store client secrets.

Required: Grant Type: authorization_code | Auth Methods: client_secret_basic client_secret_post

State Parameter:

🛡️PKCE Authorization Code Flow

🛡️ Recommended for Single Page Applications (SPAs) and Mobile Apps - No client secret needed!

Required: Grant Type: authorization_code | Auth Method: none (public client — PKCE replaces client secret)

State Parameter:

🔐 PKCE Parameters

Code Verifier: Will be generated

Code Challenge: Will be generated

Challenge Method: S256

🖥️Client Credentials Flow

Server-to-server authentication without user interaction.

Required: Grant Type: client_credentials | Auth Methods: client_secret_basic client_secret_post private_key_jwt
Note: none is not allowed — confidential client authentication is mandatory for this grant.

Two Authentication Methods: Client Secret or JWT Client Assertion

JWT Client Assertion Configuration

Use JWT client assertions for enhanced security without sharing client secrets.

Token Endpoint URL (audience):

Private Key (PEM format):

📱Device Authorization Flow

For input-constrained devices like smart TVs, gaming consoles, or IoT devices.

Required: Grant Type: urn:ietf:params:oauth:grant-type:device_code | Auth Method: none (public client — device code flow does not use client secret)

🔄Resource Owner Password Flow

For trusted applications that can securely handle user credentials. Client secret is optional!

Required: Grant Type: password | Auth Methods: client_secret_basic client_secret_post none (optional for public clients)
Deprecated in OAuth 2.1 — avoid for new integrations. Prefer Authorization Code + PKCE.

🔒 Flexible Authentication: This grant supports both traditional (with client_secret) and public client modes (without client_secret). Perfect for mobile apps and public clients!

Username/Email:

Password:

🔁JWT Bearer Grant (RFC 7523 §2.1)

Service-to-service delegated user identity. Present a signed JWT assertion (iss=client_id, sub=user) to obtain an access token on behalf of that user.

Required: Grant Type: urn:ietf:params:oauth:grant-type:jwt-bearer | Auth Methods: client_secret_basic client_secret_post private_key_jwt
This grant type must be explicitly enabled per client — it is not active by default.

🛡️ Trust model: The assertion is verified using the client's registered public key (same key used for JWT Client Assertion). The sub claim is resolved to a user by email or username.

Subject (sub) — user email or username:

Audience (aud) — token endpoint URL:

Private Key (PEM format) — same key registered for the client: This key must match the public key registered on the client application. The assertion will be signed with RS256.

Or paste a pre-built JWT assertion: If provided, this assertion is used directly (subject and private key fields above are ignored).

🎫 Token Management

🔍Token Operations

Access Token:

Refresh Token:

Refresh Token:

Required: Grant Type: refresh_token | Auth Methods: same as the original flow that issued the token

Token Exchange:

Required: Grant Type: urn:ietf:params:oauth:grant-type:token-exchange | Auth Methods: client_secret_basic client_secret_post

📊Current Token Status

Token Type: -

Expires In: -

Scopes: -

Client ID: -

👤User Information

Retrieve user profile information using your access token via the OAuth2 userinfo endpoint.

📝 Note: User information availability depends on the scopes granted during authorization. Common scopes include profile, email, and openid.

🌐 Discovery & Endpoints

🔍Endpoint Discovery

📋Available Endpoints

Authorization Endpoint: Loading...

Token Endpoint: Loading...

Introspection Endpoint: Loading...

Revocation Endpoint: Loading...

Device Authorization Endpoint: Loading...

👤 Session Management

🔐Session Operations

📝 Request/Response Log

📋HTTP Traffic Monitor

Auto-scroll to latest

Ready to log requests...

🔗 URL & Development Tools

🛠️Development Utilities

🔗 URL Parameter Parser

Parse OAuth2 callback URLs and extract parameters

URL to Parse:

🔐 PKCE Generator

Generate and validate PKCE code verifier/challenge pairs

🎫 JWT Decoder

Decode and inspect JWT tokens

JWT Token: