It seems like you're encountering a Cross-Site Request Forgery (CSRF) issue. Ory provides CSRF protection for all flows, which means that you must send a CSRF token in the body and CSRF cookie back when submitting a flow. The cookie should be sent by default by your browser, but you must add the CSRF token manually to the request body. This can be a JSON object or a native form POST ([source](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#cross-site-request-forgery-errors)). When mapping UI nodes, take note of input fields with the name

csrf_token

with the

hidden

attribute. An example of mapping the UI nodes for CSRF protection is provided in the [source](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#cross-site-request-forgery-errors). Also, it's important to note that Ory and your UI must be hosted on the same top-level domain. You can't host Ory and your UI on separate top-level domains ([source](https://www.ory.sh/docs/kratos/self-service/flows/user-login#initialize-login-flow)). If you're still encountering issues, you might want to check out the [Ory Identities documentation](https://www.ory.sh/docs/troubleshooting/csrf) for general CSRF troubleshooting, and [this document](https://www.ory.sh/docs/kratos/debug/csrf) for CSRF troubleshooting specific to self-hosted Ory Kratos Identity Server instances ([source](https://www.ory.sh/docs/troubleshooting/csrf#further-reading)).

@chilly-king-10285 who sets the csrf token? hydra or kratos

The CSRF token is set by Ory Kratos. In the context of Ory's self-service flows, Kratos takes care of all required session and CSRF cookies and ensures that all security requirements are fulfilled ([source](https://www.ory.sh/docs/kratos/self-service#browser-flows-for-server-side-apps-nodejs-php-java-)). When an app renders a form, an HTML input element with the name

csrf_token

is added. Ory Kratos compares the value of this input to the value set in the anti-CSRF cookie. If the values match, the request is allowed ([source](https://www.ory.sh/docs/kratos/concepts/security#defenses-against-cross-site-request-forgery)). In the context of Ory Hydra, it's important to note that Hydra is primarily responsible for OAuth 2.0 and OpenID Connect flows, while Kratos handles identity management and self-service flows, including login and registration.

When you navigate to the

/oauth2/auth

endpoint of Ory Hydra, an OAuth 2.0 Authorization Code flow is initiated. Here's a brief overview of what happens: 1. The client (your application) redirects the user to the

/oauth2/auth

endpoint of Ory Hydra with specific query parameters like

client_id

,

redirect_uri

,

scope

,

response_type

, and

state

. 2. Ory Hydra checks if the client is authorized to perform the request. If the client is not authorized, an error is returned. 3. If the client is authorized, Ory Hydra initiates the User Login and Consent flow. This involves redirecting the user to the login and consent apps, which are typically handled by Ory Kratos in a combined Ory setup. 4. The user logs in (if not already logged in) and gives consent to the requested scopes. 5. After successful login and consent, Ory Hydra issues an authorization code and redirects the user back to the

redirect_uri

provided by the client, with the authorization code and the original

state

parameter in the query string. 6. The client exchanges the authorization code for an access token and optionally a refresh token at the

/oauth2/token

endpoint of Ory Hydra. 7. The client can now use the access token to access the protected resources on behalf of the user. For more details, you can refer to the [Ory Hydra documentation](https://www.ory.sh/docs/hydra/5min-tutorial) and the [OAuth 2.0 security overview](https://www.ory.sh/docs/hydra/security-architecture).

The CSRF token is set during the User Login and Consent flow, which is typically handled by Ory Kratos in a combined Ory setup. When a self-service flow (like login or registration) is initiated, Ory Kratos sets a CSRF cookie in the user's browser. This cookie contains a CSRF token that is used to prevent Cross-Site Request Forgery attacks. When the user submits the form (for example, the login form), the CSRF token must be included in the request body. This CSRF token is typically included as a hidden input field in the form, with the name

csrf_token

. Ory Kratos then compares the CSRF token in the request body with the CSRF token in the cookie. If they match, the request is allowed. If they don't match, the request is rejected to prevent potential CSRF attacks. For more details, you can refer to the [Ory Kratos documentation on CSRF](https://www.ory.sh/docs/kratos/concepts/security#defenses-against-cross-site-request-forgery).

@chilly-king-10285 on which domain does it get set?

The CSRF token is set on the domain where Ory Kratos is hosted. When a self-service flow is initiated, Ory Kratos sets a CSRF cookie in the user's browser, and this cookie is associated with the domain of the Kratos server. It's important to note that Ory Kratos and your user interface (UI) must be hosted on the same top-level domain. You can't host Ory Kratos and your UI on separate top-level domains. This is due to the fact that cookies, which are used for session management and CSRF protection, are scoped to specific domains for security reasons ([source](https://www.ory.sh/docs/kratos/self-service/flows/user-login#initialize-login-flow)). If you're using a domain that's on the public suffix list (PSL), it's not possible to set cookies on that domain. In this case, you need to use a sub-domain that's not on the PSL ([source](https://www.ory.sh/docs/troubleshooting/csrf#public-suffix-domains)). Also, ensure that you use

127.0.0.1

or

localhost

consistently across your configuration, as they are considered separate domains ([source](https://www.ory.sh/docs/kratos/debug/csrf#mixing-up-127001-and-localhost)).