[Design Discussion] Relying Party Configuration for Passkey Support

[KaveeshaPiumini]

Related Feature Issue

#610

Problem Summary

Currently POC implementation initializes the WebAuthn library with a static configuration (RPID and RPOrigins). However, as an Identity Provider supporting multiple distinct applications (Relying Parties) via API and native modes, Thunder needs to support different RPIDs and Origins for each client application. We need a strategy to determine and validate these values dynamically per request or determine whether we provide an option to configure them at server level.

Proposed Approach

Implement webauthn configuration as a dynamic, request-scoped instance. Instead of a single webauthn.Config instance, it will resolve the Relying Party (RP) configuration based on the incoming request's context (e.g., the app id or the ou).

Extend the SP_APP/ORGANIZATION_UNIT in the database to store allowed_rp_ids and allowed_origins.

Instantiate or retrieve a cached webauthn configuration specifically for the identified application during the BeginRegistration and BeginLogin phases.

Technical Questions for Discussion

1. Should we create a new webauthn.New(config) instance for every request, or should we use application cache to store these instances?
2. For native apps (Android/iOS), the "origin" is often a facade or specific schema. How strictly should we validate RPID vs Origins for native clients compared to web clients?
3. Should we automatically allow subdomains of a configured RPID, or require explicit whitelisting of every origin?

Alternative Approaches

Alternative 1: Global Allowlist (Static)
Description: Configure a massive static list of all allowed RPIDs and Origins in the global config file.
Pros: Simplest implementation; no DB schema changes.
Cons: Requires a server restart/reload to add a new tenant; does not scale for a SaaS-style deployment; creates security risks if one spoofs another's RPID.

Alternative 2: User-Provided Config
Description: The client sends the desired RPID and Origin in the API request body, and Thunder trusts it.
Pros: flexible; zero configuration on the backend.
Cons: security vulnerability; A malicious client could masquerade as any Relying Party.

Architecture and Components

Application Service: API and UI support to allow admins to input Relying Party ID and Allowed Origins when creating an Application.
Authorization Service: Extract the app_id from the request.
Passkey Service: Fetches App config and constructs webauthn.Config on the fly.

Security Considerations

Must ensure that the Origin header sent by the browser strictly matches the allowlist for that specific application, preventing cross-app replay attacks.
Need to validate that the configured RPID is a valid domain suffix of the Origin to comply with WebAuthn specs.
Passkey credentials stored in the database must be scoped to the specific Organization Unit to prevent credential leakage.

Implementation Complexity

Medium (3-6 weeks)

Areas of Thunder that will be impacted

• User Management
• Authentication
• Authorization
• API Layer
• Admin Dashboard

Questions for Community Input

• Is there a performance concern with initializing the webauthn library per request?
• How should we handle default fallbacks? If an App doesn't have a configured RPID, should we fall back to the Thunder instance's global hostname, or fail the request?
• Should we strictly enforce that all Passkey integrations must define an Application entity in Thunder first? Or should we support an 'Ad-Hoc' mode for developers who want to use the API directly without prior configuration? If we support the latter, how do we ensure proper credential isolation between different ad-hoc apps?