Imagine a fictional service that signs people in at https://login.example.com. Its passkeys were registered for the relying party ID example.com. The service deliberately accepts authentication responses only from the origin https://login.example.com. These are two different settings: the relying party ID defines the credential's scope, while the accepted origin identifies where the web sign-in request is expected to begin. WebAuthn's specification separates those ideas, and Google's server guide requires checking the expected origin as part of authentication. [1][3] Passing the browser's domain-scope check is therefore not the same as being accepted by the service.

Now add a fictional shop at https://shop.example.com. That hostname sits under the same example.com domain. Under the ordinary domain rule, it can request example.com as the relying party ID, but our server still rejects an assertion whose origin is the shop because the shop is outside its chosen sign-in allowlist. [1][3] That is the puzzle this article explains. All addresses and outcomes are hypothetical, with top-level HTTPS pages, an available matching credential and no special cross-site authorization. A permitted request also still needs the user's participation and all remaining verification checks; the domain relationship does not sign anyone in automatically.

Define a hypothetical relying party with RP ID example.com and an expected-origin set containing only https://login.example.com. Assume the credential was registered under that RP ID. The RP ID and the expected origin are separate inputs to the authentication design: one scopes the credential, while the other constrains the browser context accepted by the server. The baseline domain relationship is documented in the WebAuthn Level 2 Recommendation; Google's authentication guide separately requires server-side origin verification. [1][3] Client-side permission to initiate a ceremony is not an authorization decision by the relying-party server.

For a top-level caller at https://shop.example.com, example.com satisfies the ordinary registrable-domain-suffix relationship. Nevertheless, an assertion carrying the shop origin fails this service's exact expected-origin policy. [1][3] All examples below assume normal HTTPS origins, no Related Origin Requests opt-in, no legacy AppID extension and no embedded cross-origin frame, unless a section explicitly changes an assumption. They also assume a matching credential is available and the required user interaction occurs. These conditions isolate the verification question without implying that every permitted caller can silently obtain an assertion or that a successful domain check completes authentication.

For the HTTPS addresses in our example, an origin consists of the scheme, host and port, with the normal default port omitted when it is written as a string. A page path is not part of it. [6] Thus https://login.example.com/account and https://login.example.com/help have the same origin. Adding the usual HTTPS port, 443, does not create a different origin. Using the non-default port 8443 does: https://login.example.com:8443 is a different origin from the one our fictional service accepts. A longer address is not necessarily a different origin; the parts that changed matter.

An RP ID, by contrast, is a domain string rather than a complete origin, so our example.com value contains neither https:// nor a port. [1] The browser's domain-scope decision cannot substitute for the server's more specific origin decision. This also explains why a familiar word somewhere in an address is insufficient. In https://example.com.signin.test, the actual hostname ends in signin.test; example.com is merely an earlier part of the name. Our examples are about parsed address components and domain boundaries, not how similar a logo, title or sign-in form looks to the expected site.

For an HTTPS URL, the serialized origin identifies its scheme and host, plus a non-default port when applicable. The path, query and fragment do not create a new origin. MDN's URL documentation also illustrates omission of the protocol's default port. [6] Consequently, the account and help paths under https://login.example.com share an origin, and explicitly writing :443 normalizes to that same origin. A URL using :8443 has a distinct origin. These comparisons concern ordinary HTTPS URLs; opaque, file and native-application origins are outside this worked example.

The RP ID omits scheme and port and uses a valid domain string. [1] It therefore cannot encode all the information represented by the origin. A scope check against example.com and an expected-origin check against https://login.example.com are deliberately different predicates. Hostname comparison must also respect labels: example.com.signin.test is under signin.test, not under example.com. The example illustrates why substring resemblance is not the specified domain-suffix relation. It supplies no implementation shortcut; production code should use the platform and verification library's defined origin and RP-ID handling rather than improvising string matching.

Return to the shop example. Suppose a matching credential is available and an authentication response is produced. Its client data identifies the shop's full origin. The server expects https://login.example.com, so it rejects the response under the policy we set at the start. Client data includes the origin of the requesting context, and server verification checks it against the expected sign-in origin. [2][3] The two hostnames sharing a parent domain does not erase that difference. Allowing example.com as the credential scope is not the same policy as accepting every subdomain as a sign-in page.

Now change only the page path: a request from https://login.example.com/help still has the expected origin. [6] That passes this particular check, but it does not show that the page was intended to offer sign-in or that every remaining check passes. An origin policy draws a web security boundary; it is not a review of each page's user interface. For a service owner, the useful exercise is to write down the exact origins the server should accept and compare them with the actual deployment. A response should not become acceptable merely because its origin contains a familiar name.

For the invented service, compare the assertion's collected client origin against the fixed singleton allowlist {https://login.example.com}. A response with origin https://shop.example.com fails that predicate even when its credential scope is example.com. The browser supplies the full origin in clientDataJSON, and Google's verification procedure includes matching it to the site's expected sign-in origin. [2][3] The configured expected value must represent the relying party's policy, not be inferred from an untrusted response simply to make that response pass. The example's two checks intentionally operate at different levels of specificity.

An alternate path on the approved login origin does not change this origin predicate. [6] It remains necessary to distinguish origin acceptance from application intent and from the rest of assertion verification. The example does not claim that a server can recognize a trustworthy page layout from WebAuthn fields. It shows the narrower result: a valid scope relationship does not justify broadening the expected-origin policy to all siblings. For an implementation review, compare the intended accepted origins, the configured library inputs and the actual origin received, while preserving every other verification requirement.

The response is more than a message that says which page asked. WebAuthn client data includes the operation type, challenge and origin. The authenticator's signature covers its authenticator data together with a SHA-256 hash of that client data. [2][5] The server uses the registered public key and the required verification procedure to check the response. [3] This connection matters: the site is not supposed to trust an origin field merely because somebody sent it. The claimed context must be part of the cryptographically verified response, and its values must also match what the server expected.

Imagine taking a genuine response from the shop and replacing its origin text with the approved login origin. That changes the client data covered by the signature, so the old signature is no longer valid for the altered data under the verification procedure. [5] This is a conceptual integrity example, not a request to manipulate a real sign-in. It also shows the limit of signature verification alone: a genuine signature over an unexpected shop origin can still be rejected by policy. Cryptographic consistency and acceptable context are both necessary; one does not stand in for the other.

Collected client data includes the ceremony type, encoded challenge and full origin. The assertion signature binds authenticatorData and the SHA-256 hash of clientDataJSON. [2][5] The server verifies against the stored credential public key and the applicable algorithm, then enforces the expected contextual values as part of the verification procedure. [3] Parsing a JSON origin is therefore insufficient by itself, and a signature check without the expected-origin predicate is also insufficient. The authenticated representation and the server's policy have separate roles in the acceptance decision.

Changing the origin within clientDataJSON changes the signed input represented by its hash; an existing valid signature does not authenticate the altered message. [5] Conversely, successful signature verification establishes consistency with the relevant private-key operation, not that every signed value meets the relying party's requirements. A correctly signed shop-origin response remains outside our singleton origin policy. This distinction is the core of the worked example. It assumes a conforming browser, authenticator and verification process; it is not a claim that origin binding solves compromised-client behavior or validates every application action following a login.

Our fictional service creates a new challenge for each sign-in attempt and keeps the expected value until it verifies that attempt. Google's guide calls for a challenge that is hard to predict, not reused, and discarded after use or expiry. [3] The returned client data contains an encoded form of that challenge. [2] In a paper example, we might label two challenges A and B, but those letters are only labels for different values; they are not suitable real challenges. A response for A does not answer a new request for B, even when both came from the approved login origin.

The signature connects the response to its context, while the server's saved expectation tells it which attempt that context belongs to. [2][3][5] That is why a familiar origin and a mathematically valid old signature are not enough. The server must compare against the correct current expectation and reject reuse according to its verification procedure. For someone investigating a failed sign-in, this suggests a bounded question: was the response checked against the challenge for that attempt? It does not justify printing private signing material or replacing a failed check with a more permissive one.

Challenge validation binds the response to the intended authentication attempt. Google's server guide requires a cryptographically secure, unique challenge, persistence for subsequent verification, disposal after the attempt and expiry handling; it explicitly rejects reuse. [3] clientDataJSON carries the base64url representation of the challenge. [2] Let A and B denote distinct opaque challenge byte sequences, purely as notation. A signature over the context containing A does not satisfy a verifier expecting B. The notation is not a proposal for low-entropy challenge strings, a test vector or a specific session-storage implementation.

The expected challenge must be obtained from the relying party's state for the relevant attempt rather than adopted from the response being verified. This follows from the guide's stored-expectation comparison. [3] Signature integrity establishes that the response's context has not simply been rewritten; the expected value and single-use policy establish relevance and freshness for the attempt. Both are required for the stated behavior. Origin matching alone answers neither question. The article deliberately does not prescribe a timeout duration or provide storage code, because those would add implementation choices beyond this focused verification example.

There is another way a request can pass the browser's domain check and still lack the expected credential. Suppose a fictional passkey was originally registered for login.example.com, not example.com. A page on the login host is allowed to request either scope under the ordinary rule, but the existing credential remains associated with the RP ID used when it was created. The specification and Google's guide require that authentication use the credential's matching RP ID. [1][3] Writing the broader parent domain in a later request does not relabel the earlier credential.

Keep this case separate from allowing a second origin for credentials that were already registered under example.com. In one case, the intended credential scope changed; in the other, the scope stayed fixed while the accepted calling contexts changed. [1][4] Those different changes explain different failures. A useful configuration record therefore includes the registration RP ID as well as the current request RP ID and expected origin. The record should use ordinary identifiers and documented settings. It does not need secret keys, and it should not infer the registered scope merely from the website address visible today.

A credential's RP-ID association is established during registration. Consider a credential created under login.example.com and a later get() request specifying example.com. Although either identifier can satisfy the baseline client domain relationship from the login host, the credential's own RP ID must match the requested scope. [1][3] Passing the request-scope predicate does not transform an existing credential association. This is a distinct explanation for an unavailable or rejected credential, separate from the server rejecting an assertion's origin. The example concerns logical scope and does not prescribe a migration procedure.

Changing accepted origins while retaining an RP ID and changing the RP ID itself therefore have different consequences. Related-origin configuration operates around a common chosen RP ID, whereas an already registered credential retains its original scope. [1][4] A deployment review should distinguish registration options, authentication options, stored credential metadata and expected verifier inputs. Treating all four as a single domain setting hides the failure mechanism. Preserve the actual values and their provenance, and use the relevant library and service documentation to determine the supported transition instead of assuming that a broader-looking parent name automatically covers earlier credentials.