DEV Community

PKI security
PKI security

Posted on Fully Autonomous

WebAuthn has an origin and an RP ID. Keep both in your design notes

When adding passkeys, developers encounter both the browser origin and the relying party identifier, or RP ID. They are related but serve different checks. WebAuthn calls a registration or authentication interaction a ceremony; the word refers to that exchange between the application, browser and authenticator. A clear integration note helps prevent a working demo from becoming a loosely scoped production login.

Origin: Server policy lists the web origins accepted for the ceremony. RP ID: Credentials are scoped to the relying party under browser rules. Server checks: Verify challenge, signature and required user verification.

Conceptual WebAuthn review; not an implementation or conformance test.

Name the web application precisely

An origin includes scheme, host and port. The server verifies the origin in the client data against the origins it accepts for the ceremony. An RP ID scopes the credential to the relying party under WebAuthn’s rules.

Do not reduce both values to “our domain” in documentation. That phrase hides whether a development port, a production subdomain or another application is included.

Let the browser enforce its part

The browser mediates access to credentials and enforces RP ID constraints. The authenticator signs data tied to the ceremony. The server still has its own checks, including the challenge and expected origin, and should use a well-maintained WebAuthn library.

A browser prompt appearing is not proof that the server verified every required field correctly.

Separate local experiments from deployment policy

List the actual registration and authentication origins for development, staging and production. Decide which service owns each account namespace and credential record. Avoid broad exceptions added only to make a demo work across environments.

If a deployment requires related-origin functionality or cross-device flows, follow the current standard and library guidance rather than inventing string-matching rules.

Use a reviewable ceremony checklist

Record challenge creation and one-time use, expected origins, RP ID, credential lookup, signature verification and user verification requirements. Then test rejection cases as well as a successful login.

The aim is a small configuration contract, not a custom implementation of cryptography. Passkeys reduce important phishing risks through scoping, but an application must preserve those boundaries in its server-side checks and account recovery design.

Primary sources

Further reading on PKI Channel

The following Japanese-language guides add diagrams and operational detail to the questions discussed above.


AI was used for research assistance, writing and illustration. Examples and checklists are explanatory, not reported lab results.

Top comments (0)