bland-finland-95044
07/23/2025, 3:20 PMbrief-egg-61061
07/23/2025, 3:20 PMbrief-egg-61061
07/23/2025, 3:20 PM/admin/recovery/link
with your API key and the required parameters: bash curl --request POST \ --header "Authorization: Bearer {ORY_API_KEY}" \ --header "Content-Type: application/json" \ --data '{ "expires_in": "12h", "identity_id": "$ACCOUNT_ID" }' https://$<http://PROJECT_SLUG.projects.oryapis.com/admin/recovery/link|PROJECT_SLUG.projects.oryapis.com/admin/recovery/link>
- identity_id
is the ID of the user you want to create the recovery link for. - expires_in
is optional and sets how long the link is valid (e.g., "12h" for 12 hours). If omitted, it defaults to your configuration. The response will include a recovery_link
and its expires_at
timestamp: json { "recovery_link": "<https://your-project.projects.oryapis.com/self-service/recovery?flow=...&token=...>", "expires_at": "2022-02-25T03:09:37.60684766Z" }
[Administrative account recovery – Magic links](https://www.ory.sh/docs/kratos/manage-identities/account-recovery#magic-links) ### Using the Ory CLI While the knowledge sources describe how to update your configuration with the CLI, they do not provide a direct CLI command for creating a recovery link. The recommended approach for creating a recovery link is to use the REST API as shown above. If you need to update your configuration for recovery flows, you can use the CLI to download, edit, and upload your identity config, but the actual creation of a recovery link for a user is done via the REST API. --- Note: You need an API key with sufficient permissions to call the admin endpoint. The recovery link is not sent automatically to the user; you must send it to them yourself after generating it [Administrative account recovery – Magic links](https://www.ory.sh/docs/kratos/manage-identities/account-recovery#magic-links).bland-finland-95044
07/23/2025, 4:18 PMbrief-egg-61061
07/23/2025, 4:18 PMbrief-egg-61061
07/23/2025, 4:18 PMcode
or `link`—for each flow. For example, in the recovery flow configuration, you set the method with the use
parameter: yaml selfservice: flows: recovery: use: code # or 'link', but not both
The documentation explicitly states: "Just one recovery method can be enabled at a time. The code
method is enabled by default in all new Ory Network projects" and "When you change the strategy from link
to code
in an existing project, you might need to adjust your UI" [Integration basics – Recovery](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#recovery) [Account recovery and password reset](https://www.ory.sh/docs/kratos/self-service/flows/account-recovery-password-reset#configuration). So, you must choose either codes or magic links for each flow, not both at the same time.bland-finland-95044
07/23/2025, 5:14 PM{
"id": "27e07287-7e8f-49fc-819d-f8f1d4fc12d7",
"error": {
"code": 403,
"id": "security_identity_mismatch",
"message": "The requested action was forbidden",
"reason": "The request was initiated by someone else and has been blocked for security reasons. Please go back and try again.",
"status": "Forbidden"
},
brief-egg-61061
07/23/2025, 5:14 PMbrief-egg-61061
07/23/2025, 5:15 PMjson { "code": 403, "id": "security_identity_mismatch", "message": "The requested action was forbidden", "reason": "The request was initiated by someone else and has been blocked for security reasons. Please go back and try again.", "status": "Forbidden" }
means that the flow was interrupted because the session or identity making the request does not match the one that initiated the flow. This is a security feature in Ory to prevent actions from being performed by a different user than the one who started the flow. Common causes: - The user started a flow (e.g., recovery, settings) and then logged in as a different user before completing the flow. - The session changed (e.g., user logged out and another user logged in) between starting and completing the flow. - The flow was initiated in one browser or device and completed in another, causing a mismatch. How to resolve: - Ensure the same user who started the flow is the one completing it. - If the session has changed, restart the flow from the beginning. This behavior is documented in the Ory API reference, which states that a security_identity_mismatch
error occurs if the flow was interrupted and a different identity is now logged in, or if the requested return_to
address is not allowed by configuration. The recommended action is to redirect the user to start the flow again with the correct session or identity [updateSettingsFlow](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json). If you continue to see this error, double-check your application's session handling and ensure users are not switching accounts or browsers/devices during the flow.bland-finland-95044
07/23/2025, 5:58 PM{
"id": "a0c44149-d274-45e7-9679-508e2674e3c1",
"error": {
"code": 403,
"id": "security_identity_mismatch",
"message": "The requested action was forbidden",
"reason": "The request was initiated by someone else and has been blocked for security reasons. Please go back and try again.",
"status": "Forbidden"
},
"created_at": "2025-07-23T17:57:09.51066Z",
"updated_at": "2025-07-23T17:57:09.51066Z"
brief-egg-61061
07/23/2025, 5:58 PMbrief-egg-61061
07/23/2025, 5:58 PMsecurity_identity_mismatch
with a 403 status indicates that the recovery flow was started by one identity (user/session), but the request to complete the flow is being made by a different identity or session. This is a security feature in Ory to prevent actions from being completed by someone other than the original requester. Even if you open the recovery link in an incognito browser, this error can occur if: - The session that initiated the recovery flow is not present in the browser where you are opening the link. - The recovery flow expects the same session (or no session) as when it was started, but a different session or identity is detected, or none is found. Ory's documentation explains that this error happens when "the flow was interrupted with session_refresh_required
but apparently some other identity logged in instead," or when the session does not match the one that started the flow. The recommended action is to restart the recovery flow and ensure you complete it in the same browser and session context as it was initiated [updateSettingsFlow](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json). If you consistently see this error even in incognito mode, it may be due to how your application or Ory project is configured to handle sessions and recovery flows. Double-check that you are not logged in as a different user or that there are no conflicting sessions. If the problem persists, consider restarting the recovery process and ensure you use the same browser window for the entire flow. If you are using a custom UI or integration, verify that session handling is implemented according to Ory's guidelines.bland-finland-95044
08/01/2025, 4:10 PMbrief-egg-61061
08/01/2025, 4:10 PMbrief-egg-61061
08/01/2025, 4:10 PM<http://127.0.0.1:41805/callback?code=ory_ac>...
that you see after logging in with the Ory CLI is part of the Ory CLI's authentication flow. When you run commands like ory tunnel
or log in to the CLI, the CLI opens a browser window for you to authenticate with your Ory Network account. After successful authentication, the Ory Network redirects your browser to a local callback URL (such as `http://127.0.0.1:41805/callback`) with an authorization code as a query parameter. This local callback URL is a temporary HTTP server started by the Ory CLI on your machine to securely receive the authentication code from the browser. The CLI then exchanges this code for an access token to authenticate further CLI commands. This is a standard OAuth2 device/browser login pattern for CLI tools. Why does this happen? - The Ory CLI needs to authenticate you with the Ory Network. - It starts a local HTTP server on a random port (e.g., 41805). - After you log in via the browser, Ory Network redirects to this local server with the code. - The CLI captures the code and completes the authentication process. This behavior is described in the Ory documentation, which notes that "authentication via ORY_PROJECT_API_KEY or browser-based sign-in is required" and that the CLI "connects your application and Ory's APIs through a local HTTP server" for authentication purposes [ory tunnel](https://www.ory.sh/docs/cli/ory-tunnel#ory-tunnel). In summary: The redirect to <http://127.0.0.1:41805/callback?code=ory_ac>...
is expected and is how the Ory CLI securely receives your authentication code after you log in via the browser.bland-finland-95044
08/01/2025, 4:16 PMbrief-egg-61061
08/01/2025, 4:16 PMbrief-egg-61061
08/01/2025, 4:16 PMory tunnel
) inside Docker, the browser-based authentication flow can be problematic because the CLI starts a temporary local HTTP server on a random port (e.g., 127.0.0.1:41805
) to receive the authentication callback. This port is only accessible inside the Docker container, not from your host machine or browser, so the authentication cannot complete successfully. How to solve this? The official Ory documentation recommends using a Project API Key for authentication in automated or headless environments (like Docker). This avoids the need for browser-based login and the random callback port entirely. You can do this by: 1. Create a Project API Key in the Ory Console. 2. Set the API key as an environment variable in your Docker container: bash ENV ORY_PROJECT_API_KEY=<your-api-key>
3. Run the Ory CLI with the -q
(quiet) flag to suppress browser login: bash ory tunnel -q --project <project-id> <http://localhost:3000>
This approach allows the CLI to authenticate non-interactively and is the recommended way to use ory tunnel
in Docker or CI environments [ory tunnel documentation](https://www.ory.sh/docs/cli/ory-tunnel#ory-tunnel). > Summary: > When using ory tunnel
in Docker, avoid browser-based login and the random callback port by using a Project API Key and the -q
flag for non-interactive authentication. If you need to run the browser-based login flow, you would have to expose the random callback port from the container to your host, but this is not practical or recommended. The API key method is the supported and documented solution for this scenario.