For the complete documentation index, see llms.txt

Best practices

This page contains useful information about best practices and considerations for anyone involved in implementing Passkeys, for example developers, project managers and technical architects.

For the complete documentation index, see llms.txt

The scope is for select topics that can assist you during your integration, such as key decisions, tips and ways to avoid common issues.

Handling redirects and Content Security Policy (CSP)

For the complete documentation index, see llms.txt

When a passkey registration or authentication finishes, the end-user's browser carries out the final redirect to your provided rpRedirectUri. As this is a client-side action, you must account for browser security policies and verify that the operation was successfully completed.

Important

The end-user is redirected to the landing page in the rpRedirectUri regardless of the outcome of the registration or authentication operation.

That is why this page must never grant access or assume success without verifying that the operation was successfully completed.

If your rpRedirectUri redirects to another host or domain, the browser's Content Security Policy (CSP) will block it, whereas redirecting to another page on the same server usually works.

Example: Redirect blocked by CSP

From: https://www.mydomain.com
To:   https://mydomain.com

Example: Redirect not blocked by CSP

From: https://www.mydomain.com/first-page
To:   https://www.mydomain.com/second-page

If the browser's CSP blocks the redirect, the end-user may see an error page or appear stuck. However, the underlying passkey operation has already completed on the backend. As this is a browser-side redirect failure, it does not appear in the Signicat audit logs or API responses.

Our recommendation

As you cannot see browser-side redirect failures in the Signicat audit logs or API responses, we recommend that you test your redirect flow end-to-end before deploying to production.

Clearing browser cookies

For the complete documentation index, see llms.txt

If the end-user's browser becomes unresponsive or appears stuck during a passkeys operation, then we recommend that you ask the end-user to clear their browser cookies and to try again.

As this is a browser-side issue, no error message is generated, and it does not appear in the Signicat audit logs or API responses.

Choose events (callback) or polling

Events are our way of letting you know when something happens in one of our services. When an asynchronous operation completes, or when ReuseID gets a notification that a device has changed state, ReuseID publishes an event with the operation result.

For the complete documentation index, see llms.txt

You can use the Signicat events service to subscribe to events, so that you automatically receive the result at your specified notification URI. This is often referred to as callback.

You can also get the operation result back through polling. The result that you receive through the Signicat events service is the same as the result obtained by polling, but wrapped in a Signicat event object.

For production, we always recommend that you use the Signicat events service instead of polling. This offers the best usability and responsiveness, as it has the least amount of latency. It also means that you do not need to conduct additional polling calls.

Want to learn more?

• For information generic to all Signicat events, see the general Events documentation.
• For information specific to Passkeys, see the Passkeys section in the ReuseID Events documentation.