Relying parties (RPs) are crucial to ensuring passkeys are phishing-resistant. We explain what relying parties are in more detail and how to configure them.
A relying party (RP) is responsible for issuing and authenticating passkeys. Typically, a relying party is in charge of the server-side and client ceremonies. This involves a server dedicated to registering, storing, and verifying the credentials generated by these passkeys on the client. The client application initiates the passkey generation and verification process. Web-based client applications achieve this through the WebAuthn browser API, whereas native mobile applications achieve this through their respective operating system (OS) SDKs and association mechanisms.
Why Relying Parties Play a Crucial Role in Making Passkeys Phishing Resistant
Relying parties are essential in ensuring the effectiveness and security of passkeys, particularly in providing phishing-resistant authentication. Here’s how they contribute to this vital security feature:
1. Binding Credentials to Specific Origins
One of the fundamental principles that make passkeys phishing-resistant is the binding of credentials to specific web origins. When a passkey is registered, the RP ensures that the credentials are tied to its specific domain (or a registrable suffix of that domain). This means that credentials created for login.example.com cannot be used on phishing-site.com, even if the phishing site tries to mimic the legitimate one. The browser enforces this origin binding, ensuring that passkeys are only used in the correct context. This domain is referred to as the Relying Party ID (rpID).
2. Control Over Registration and Authentication Processes
Through the WebAuthn API, relying parties have complete control over the registration and authentication ceremonies. By managing these processes, RPs can enforce strict security measures, such as requiring hardware-backed authenticators or setting high assurance levels for authentication. This control helps ensure that only genuine and secure credentials are created and used.
3. Verification of Authenticator Responses
During the authentication process, the RP validates the authenticator's responses. This includes checking the authenticity of the cryptographic signatures generated by the private key stored on the user's device. The RP must verify that the response is correctly signed and corresponds to the public key registered during the initial setup. This validation process prevents attackers from using stolen or forged credentials to gain unauthorized access.
How to choose the best Relying Party ID (rpID) for your application
Because the binding of the relying party is a crucial component of a passkey registration and authentication ceremony, choosing a rpID is an important decision before turning passkeys on for your users. By its nature, passkeys are tightly bound to their rpID, so changing it after a passkey rollout can become problematic.
The simplest approach is to choose the highest level parent domain as your rpID, for example, yourwebsite.com. By choosing this as your rpID, you can use the passkey across both the parent domain and all subdomains, for example, app1.yourwebsite.com and app2.yourwebsite.com. Do note that this doesn’t apply the other way around; if you register a passkey with a rpID of app1.yourwebsite.com the passkey is strictly bound to that domain and can’t be used on any other domain, apart from its children subdomain.app1.yourwebsite.com.
The next question that typically follows this is, what happens if I have other domains like yourwebsite.com.au or yourwebsite.co.uk. This scenario constitutes a cross-origin registration. As of this blog post (July 2024), cross-origin passkey registration is still in the early roll-out phases amongst browsers and not widely supported as this specification is a relatively new addition to the WebAuthn API spec. This means that even with an iframe originating from yourwebsite.com, if the parent origin is yourwebsite.com.au then you’d be unable to register passkeys on most browsers. This doesn’t apply to cross-origin verification; if a passkey was registered on yourwebsite.com you’d be able to do a verification process on yourwebsite.co.uk provided you add the domain https://yourwebsite.co.uk to the list of expected origins. This may sound a bit complicated, but the reason for this is to ensure all the domain properties bind to the passkey while allowing a level of controlled flexibility, and we will keep this post up to date on the coverage of cross-origin registration.
How can Authsignal help?
Authsignal makes it easy to start deploying passkeys even in your existing infrastructure or applications without migration. We simplify things like setting up your relying party ID through our easy steps. Authsignal also provides pre-built UI flows that are tuned for all the different scenarios. If full customization is your preference, Authsignal provides both browser, mobile, and full API control to build user experiences that meet your requirements.
.png)
