To add passkey and WebAuthn support in the self-hosted open-source version of Ory Kratos, you need to modify the configuration file. Here's how you can do it: 1. For WebAuthn: Add the following configuration to your

kratos.config.yml

file:

yaml selfservice:   methods:     webauthn:       config:         passwordless: false         rp:           display_name: SAMPLE_NAME           # Set 'id' to the top-level domain.           id: <http://loginpage.com|loginpage.com>           # Set 'origin' to the exact URL of the page that prompts the user to use WebAuthn. You must include the scheme, host, and port.           origin: <https://loginpage.auth.com:4455>       enabled: true

Make sure to adjust the

display_name

,

id

, and

origin

values according to your setup. 2. For Passkey: Add the following configuration to your

kratos.config.yml

file:

yaml selfservice:   methods:     passkey:       enabled: true       config:         rp:           display_name: Your Application name           # Set 'id' to the top-level domain.           id: localhost           # Set 'origin' to the exact URL of the page that prompts the user to use WebAuthn. You must include the scheme, host, and port.           origins:             - <http://localhost:4455>

Again, adjust the

display_name

,

id

, and

origins

values to match your setup. Additionally, you may need to update your identity schema to support passkeys. Add the following to your `identity.schema.json`:

json {   "$schema": "<http://json-schema.org/draft-07/schema#>",   "type": "object",   "properties": {     "traits": {       "type": "object",       "properties": {         "email": {           "type": "string",           "format": "email",           "title": "Your E-Mail",           "minLength": 3,           "<http://ory.sh/kratos|ory.sh/kratos>": {             "credentials": {               "passkey": {                 "display_name": true               }             }           }         }       }     }   } }

This configuration enables both WebAuthn and Passkey methods in your self-hosted Ory Kratos instance. Sources: [Configure multi-factor authentication in Ory Kratos](https://www.ory.sh/docs/kratos/self-hosted/mfa) [Passkeys with the dedicated passkey strategy](https://www.ory.sh/docs/kratos/passwordless/passkeys#passkeys-with-the-dedicated-passkey-strategy)

The 'id' in the configuration refers to the top-level domain, not the full URL. This is an important distinction in the WebAuthn and Passkey configurations for Ory Kratos. Let me explain based on the information from the knowledge sources: 1. For WebAuthn: [Configure multi-factor authentication in Ory Kratos](https://www.ory.sh/docs/kratos/self-hosted/mfa) states:

yaml rp:   display_name: SAMPLE_NAME   # Set 'id' to the top-level domain.   id: <http://loginpage.com|loginpage.com>   # Set 'origin' to the exact URL of the page that prompts the user to use WebAuthn. You must include the scheme, host, and port.   origin: <https://loginpage.auth.com:4455>

2. For Passkey: [Passkeys with the dedicated passkey strategy](https://www.ory.sh/docs/kratos/passwordless/passkeys#passkeys-with-the-dedicated-passkey-strategy) provides a similar example:

yaml rp:   display_name: Your Application name   # Set 'id' to the top-level domain.   id: localhost   # Set 'origin' to the exact URL of the page that prompts the user to use WebAuthn. You must include the scheme, host, and port.   origins:     - <http://localhost:4455>

In both cases, the comments explicitly state to set the 'id' to the top-level domain. The 'origin' or 'origins' field is where you specify the full URL, including the scheme, host, and port. This distinction is crucial because the 'id' is used as the Relying Party ID in WebAuthn and Passkey implementations, which must be a registrable domain suffix of, or equal to, the current domain. The full URL is not appropriate for this purpose.

Yes, you will encounter cross-origin issues with this setup. There are several reasons for this: 1. Different domains: Your Ory Kratos instance is running on an IP address (

15.206.71.188

) while your UI is on a different domain (

<http://ory-kratos-frontend.onrender.com|ory-kratos-frontend.onrender.com>

). This is a classic cross-origin scenario. 2. HTTP vs HTTPS: Your Kratos instance is using HTTP while your frontend is using HTTPS, which adds another layer to the cross-origin issues. 3. Cookie domain mismatch: Ory Kratos uses cookies for sessions and CSRF protection, and these cookies won't work across different domains. According to the documentation: > "Ory and your UI must be on the hosted on same top level domain. You can't host Ory and your UI on separate top level domains: > -

<http://ory.bar.com|ory.bar.com>

and

<http://app.bar.com|app.bar.com>

will work; > -

<http://ory.bar.com|ory.bar.com>

and

<http://bar.com|bar.com>

will work; > -

<http://ory.bar.com|ory.bar.com>

and

<http://not-bar.com|not-bar.com>

will not work." [Login Flow Documentation](https://www.ory.sh/docs/kratos/self-service/flows/user-login#initialize-login-flow) To solve this issue, you have several options: 1. Configure CORS: Enable and properly configure CORS in your Kratos configuration:

yaml serve:   public:     cors:       enabled: true       allowed_origins:         - <https://ory-kratos-frontend.onrender.com>       allowed_methods:         - POST         - GET         - PUT         - PATCH         - DELETE       allowed_headers:         - Authorization         - Cookie         - Content-Type       exposed_headers:         - Content-Type         - Set-Cookie

[Cross-origin resource sharing settings](https://www.ory.sh/docs/kratos/guides/setting-up-cors) 2. Use a reverse proxy: Set up a reverse proxy (like Nginx, Caddy, or Oathkeeper) to serve both your Kratos instance and UI from the same domain. 3. Host on same domain: The most reliable solution is to host both services on the same domain, possibly using different paths. For local development, you can use [Ory Tunnel](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#debug) to avoid CORS issues. Note that even with CORS configured, you may still face issues with cookies and authentication flows due to the different domains. The recommended approach is to use the same domain for both services.