https://www.ory.sh/ logo
Join Slack
Powered by
<@U04UQ68083H> can you tell me in which cases an e...
# ory-copilot
i
@chilly-king-10285 can you tell me in which cases an error response contains a 
redirectTo
address and where it redirects by default
b
A message from kapa.ai
An error response contains a 
redirect_to
address in the following cases: ### Ory Kratos (Identity Management) - Self-Service Flows (Login, Registration, etc.): - When a user-facing error occurs in the browser, Ory Kratos redirects the user's browser to the Error UI URL configured via 
selfservice.flows.error.ui_url
. The error context is passed as a query parameter, and your UI can fetch the error details from the Kratos API. The redirection target is whatever you set in your configuration, not a hardcoded default. - For regular flow completions (not errors), the browser is redirected to a URL defined by the following configuration keys: - 
selfservice.default_browser_return_url
(global default) - 
selfservice.flows.<flow>.after.default_browser_return_url
(per-flow, e.g., login, registration) - 
selfservice.flows.<flow>.after.<method>.default_browser_return_url
(per-method, e.g., password, OIDC) - You can also use the 
?return_to=
query parameter when initializing a flow, but the domain must be whitelisted in 
selfservice.allowed_return_urls
[Redirection configuration](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection), [Redirect flows](https://www.ory.sh/docs/concepts/redirects#redirect-flows). ### Ory Hydra (OAuth2 & OpenID Connect) - OAuth2 Flows (Login, Consent, Logout): - When accepting login, consent, or logout requests via the admin API (
acceptOAuth2LoginRequest
, 
acceptOAuth2ConsentRequest
, 
acceptOAuth2LogoutRequest
), the response contains a 
redirect_to
field. This is the URL to which you should redirect the user's browser to complete the flow. The actual redirect target is determined by the OAuth2 flow and client configuration, not a fixed default [acceptOAuth2LoginRequest](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json), [acceptOAuth2ConsentRequest](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json), [acceptOAuth2LogoutRequest](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json). ### Ory Oathkeeper (Access Proxy) - Error Handlers: - If the 
redirect
error handler is enabled and matches the error condition (e.g., unauthorized access), Ory Oathkeeper returns an HTTP 302/301 redirect to the configured 
to
address. You can also append the original URL using 
return_to_query_param
. The default is to return a JSON error unless you configure the redirect handler and its conditions [Oathkeeper error handlers](https://www.ory.sh/docs/oathkeeper/pipeline/error#error-handlers), [Error matching](https://www.ory.sh/docs/oathkeeper/pipeline/error#error-matching). ### Summary Table | Product | When is 
redirect_to
present? | Default redirect behavior | |--------------|-----------------------------------------------|------------------------------------------| | Kratos | On error (to error UI), on flow completion | Configurable via 
selfservice.*
keys | | Hydra | On login/consent/logout accept API responses | Determined by OAuth2 flow/client config | | Oathkeeper | If 
redirect
error handler matches | No redirect unless configured | If you need more details for a specific product or flow, let me know!
i
@chilly-king-10285 that does not fully answer my question. in the api specs of kratos there is e.g.
Copy code
ErrorBrowserLocationChangeRequired
or
Copy code
ErrorAuthenticatorAssuranceLevelNotSatisfied
and many more, also i expect hydra to have similar errors. I would like to have a list of all errors, where they are thrown and what the redirect_browser_to value would contain by default in each case
b
A message from kapa.ai
Based on the provided knowledge sources, here is what can be determined about error responses containing a 
redirect_browser_to
(Kratos) or 
redirect_to
(Hydra) field, when they are thrown, and what the redirect value contains by default: --- ## Ory Kratos ### Error Types with 
redirect_browser_to
- ErrorBrowserLocationChangeRequired - When is it thrown? - When a flow requires the browser to change its location, typically in Single Page Applications (SPAs) when a new flow must be started (e.g., after a flow expires or is invalid). - What does 
redirect_browser_to
contain? - It contains the URL to which the browser should be redirected to continue or restart the flow. This is typically a UI endpoint with a new flow ID, e.g., 
/ui/login?flow=<new-flow-id>
. - The value is not a fixed default; it is dynamically generated based on the new flow and your UI configuration. - Example response:
Copy code
json       {         "error": {           "id": "browser_location_change_required",           "code": 422,           "status": "Unprocessable Entity",           "reason": "In order to complete this flow please redirect the browser to: /ui/login?flow=ad574ad7-1a3c-4b52-9f54-ef9e866f3cec",           "message": "browser location change required"         },         "redirect_browser_to": "/ui/login?flow=ad574ad7-1a3c-4b52-9f54-ef9e866f3cec"       }
[SPAs and the '422' error](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration#spas-and-the-422-error) - Other Errors (e.g., ErrorAuthenticatorAssuranceLevelNotSatisfied, errorGeneric) - When are they thrown? - These are thrown in various situations, such as when the required authenticator assurance level is not met, or when a resource is not found, etc. - What does 
redirect_browser_to
contain? - For most errors (e.g., 410 Gone, 422 Unprocessable Entity), the error response may include a 
redirect_browser_to
field if the error requires the browser to be redirected. - The actual value is context-dependent and typically points to a UI endpoint (e.g., error page or new flow page). - If the error is a user-facing error, Kratos redirects to the error UI URL configured via 
selfservice.flows.error.ui_url
(e.g., `https://example.org/errors?id=&lt;error-id&gt;`). - There is no single "default" value; it depends on your configuration and the flow in question. [User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors) #### Example: updateLoginFlow, updateSettingsFlow, updateRecoveryFlow - For these endpoints, a 422 error may include:
Copy code
json   {     "error": { ... },     "redirect_browser_to": "<URL to redirect the user to next>"   }
The URL is dynamically generated and points to the appropriate UI for the next step or error handling, as configured in your Kratos deployment. [updateLoginFlow](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json), [updateSettingsFlow](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json), [updateRecoveryFlow](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json) --- ## Ory Hydra ### Error Responses with 
redirect_to
- OAuth2 Flows (Login, Consent, Logout) - When accepting or rejecting login, consent, or logout requests, the response contains a 
redirect_to
field. - When is it thrown? - After processing the request (accept or reject), Hydra returns a 
redirect_to
URL to which the user's browser should be redirected to complete the OAuth2 flow. - What does 
redirect_to
contain? - The value is the URL that continues the OAuth2 flow, typically back to the client application or to an error page, depending on the flow and outcome. - The value is not a fixed default; it is determined by the OAuth2 flow, client configuration, and the state of the request. [acceptOAuth2LoginRequest](https://raw.githubusercontent.com/ory/hydra/master/spec/api.json), [acceptOAuth2ConsentRequest](https://raw.githubusercontent.com/ory/hydra/master/spec/api.json), [acceptOAuth2LogoutRequest](https://raw.githubusercontent.com/ory/hydra/master/spec/api.json), [rejectOAuth2LoginRequest](https://raw.githubusercontent.com/ory/hydra/master/spec/api.json), [rejectOAuth2ConsentRequest](https://raw.githubusercontent.com/ory/hydra/master/spec/api.json) --- ## Summary - There is no single default value for 
redirect_browser_to
or 
redirect_to
. The value is always context-dependent, based on your configuration (for Kratos) or the OAuth2 flow/client (for Hydra). - A list of all possible errors and their redirect behavior is not fully enumerated in the provided knowledge sources. The documentation and API specs show that errors requiring a redirect will include the appropriate field, and the value will point to the next step in the flow or an error UI, as configured. If you need a full list of all error types and their redirect behavior, this information is not explicitly enumerated in the provided knowledge sources. The sources do, however, describe the general mechanism and configuration points for these redirects.
i
@chilly-king-10285 ok it there a pattern on which i can identify if the error is userfacing, or not?
b
A message from kapa.ai
Based on the provided knowledge sources, there is no explicit, documented pattern (such as a naming convention or a specific field) that allows you to programmatically determine if an error is "user-facing" or not. However, the documentation does describe how user-facing errors are handled in Ory Kratos: - User-facing errors are those that are meant to be shown to end users, typically occurring during self-service flows (login, registration, etc.). When such an error occurs, Kratos redirects the browser to the configured Error UI URL, passing the error ID as a query parameter. Your UI then fetches the error details from the 
/self-service/errors
endpoint, which returns a JSON object with fields like 
code
, 
message
, 
reason
, and 
debug
 [User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors). - API errors (for API clients) are returned directly in the HTTP response and do not involve a redirect. The documentation does not provide a comprehensive list or a clear pattern (such as a prefix or error code range) to distinguish user-facing errors from others. The distinction is primarily based on the context in which the error occurs (browser flow vs. API flow) and how your application is configured to handle errors. In summary: There is no explicit pattern or field in the error object that marks an error as user-facing according to the knowledge sources. The determination is based on the flow context and your configuration, not on a specific error property or naming convention [User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors).
i
@chilly-king-10285 ok, and in hydra i can configure endpoints: hydra_urls_login /ui/login hydra_urls_registration /ui/registration hydra_urls_consent /ui/consent hydra_urls_logout /ui/logout hydra_urls_error /ui/error this is the default, if i have a custom domain so api and ui are on different domains do i always have to provide full domain, or is still possible to use relative path?
b
A message from kapa.ai
For Ory Hydra, when configuring endpoints such as 
hydra_urls_login
, 
hydra_urls_registration
, 
hydra_urls_consent
, 
hydra_urls_logout
, and 
hydra_urls_error
, the knowledge sources do not explicitly state whether you must use fully qualified URLs (including the domain) or if relative paths are supported when your API and UI are on different domains. However, the documentation and examples consistently show the use of fully qualified URLs (including the scheme and domain) for these settings, especially in production or when services are running on different domains. For example, in the Docker deployment and configuration examples, the URLs are always set as full URLs like 
<https://localhost:5444/>
or 
<http://localhost:9020/login>
 [Deploy Ory Hydra](https://www.ory.sh/docs/hydra/self-hosted/configure-deploy#deploy-ory-hydra). There is no mention in the knowledge sources of support for relative paths in these settings when using custom domains. Therefore, to ensure correct behavior when your API and UI are on different domains, you should provide the full URL (including the domain) for each endpoint. If you only provide a relative path, Hydra may not be able to resolve it correctly across different domains, which could lead to misrouted requests or errors. Summary: When using custom domains and your API and UI are on different domains, you should use fully qualified URLs for Hydra endpoint configuration. The knowledge sources do not indicate support for relative paths in this scenario [Deploy Ory Hydra](https://www.ory.sh/docs/hydra/self-hosted/configure-deploy#deploy-ory-hydra).
i
@chilly-king-10285 already did that, but it makes it hard to redirect my SPA, is there another way to then making a same site check on my side in the code
b
A message from kapa.ai
I'm sorry, but the knowledge sources do not provide a documented alternative to using fully qualified URLs for Hydra's UI endpoints when your API and UI are on different domains, nor do they describe a built-in mechanism for handling SPA redirects based on same-site checks in your application code. The documentation and examples consistently use full URLs for these settings, and there is no mention of a recommended pattern for dynamically determining the correct redirect target for SPAs across domains, nor any built-in support for relative paths in this scenario. If you need more flexibility, you may need to implement custom logic in your SPA to handle redirects after authentication, but this approach is not covered in the provided knowledge sources. If you have a specific use case or scenario, you may want to consider raising it in the Ory community or checking for updates in the official documentation.
i
@chilly-king-10285 if an oauth client requests, i want the user to always verify with his credentials before the auth flow passes no matter if the user is logged in or not. i have properly implemented it within my UI, but nevertheless isnt it in theory possible that someone if he has a valid session can pass the oauth flow by just using api requests and not interacting with the api?
b
A message from kapa.ai
Yes, in theory, if a user has a valid session cookie, it is possible for them to complete the OAuth2 flow by making direct API requests—bypassing your UI—unless you explicitly enforce re-authentication at the backend. By default, Ory OAuth2 (Hydra) checks for an existing session and, if found, may allow the OAuth2 flow to proceed without prompting the user to re-enter credentials. This is the standard behavior unless you configure the flow to require re-authentication. The 
prompt=login
parameter can be used in the OAuth2 authorization request to force the login UI to be shown, even if a session exists. However, if your backend (login provider) does not enforce credential verification and simply accepts the session, an attacker (or user) with a valid session cookie could bypass the UI and complete the flow via API calls. To guarantee that the user must always verify their credentials (e.g., re-enter their password) before proceeding with the OAuth2 flow, you must enforce this check in your login provider logic, not just in the UI. This means that, even if a valid session exists, the backend should require the user to re-authenticate when the OAuth2 flow is initiated with 
prompt=login
or similar mechanisms. Otherwise, as you noted, someone could use a valid session cookie to pass the flow without user interaction. The knowledge sources confirm that session checks and the use of 
prompt
parameters are part of the flow, and that the login provider is responsible for handling authentication logic. If you want to enforce re-authentication, you must implement this in your backend logic, not just in the frontend UI [Custom-login-consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow), [Authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). Summary: Yes, without backend enforcement, a valid session can be used to bypass UI-based credential checks. To prevent this, ensure your backend requires credential verification for every OAuth2 flow, regardless of session state.
i
@chilly-king-10285 so i can apply prompt=login to my hydra implementation?
b
A message from kapa.ai
A message from kapa.ai
Yes, you can use 
prompt=login
in your Hydra implementation. According to the Ory documentation, the 
prompt
parameter is supported in the OAuth2 authorization code flow. Setting 
prompt=login
instructs the Authorization Server (Hydra) to prompt the user to log in before processing the access request, even if a session already exists. This is the standard way to force re-authentication in OAuth2 and OpenID Connect flows with Ory Hydra [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). However, you must ensure that your login provider (the service handling the login UI and logic) respects this parameter and actually requires the user to re-enter their credentials, not just rely on an existing session. The backend logic should enforce this behavior for 
prompt=login
requests [Custom-login-consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow).
Yes, you can apply 
prompt=login
to your Hydra implementation. The Ory documentation explicitly states that the 
prompt
parameter is supported in the OAuth2 authorization code flow. Using 
prompt=login
will instruct Ory Hydra to prompt the user to log in before processing the access request, even if a session already exists. This is the standard way to force re-authentication in OAuth2 and OpenID Connect flows with Ory Hydra [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). However, you must ensure that your login provider (the service handling the login UI and logic) respects this parameter and actually requires the user to re-enter their credentials, not just rely on an existing session [Custom-login-consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow).
A message from kapa.ai
Yes, you can apply 
prompt=login
to your Hydra implementation. The Ory documentation confirms that the 
prompt
parameter is supported in the OAuth2 authorization code flow. Setting 
prompt=login
instructs the Authorization Server to prompt the user to log in before processing the access request, even if a session already exists. This is the standard way to force re-authentication in OAuth2 and OpenID Connect flows with Ory Hydra [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). However, you must ensure that your login provider (the service handling the login UI and logic) respects this parameter and actually requires the user to re-enter their credentials, not just rely on an existing session [Custom-login-consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow).
i
@chilly-king-10285 i dont still quite get it can you show me a code example, or write one for the typscript client
b
A message from kapa.ai
Certainly! Here’s a code example that demonstrates how to initiate an OAuth2 authorization code flow with Ory Hydra using the 
prompt=login
parameter, using TypeScript and the Ory JavaScript client. This will force the login UI to be shown, even if a session exists.
Copy code
typescript import { Configuration, PublicApi } from "@ory/client"  const ory = new PublicApi(   new Configuration({     basePath: "https://<your-project-slug>.<http://projects.oryapis.com|projects.oryapis.com>",   }) )  const clientId = "your_client_id" const redirectUri = "<https://your-app.com/callback>" const state = "random_state_value" const scope = "openid" const prompt = "login"  const authorizationUrl = `https://<your-project-slug>.<http://projects.oryapis.com/oauth2/auth?response_type=code&client_id=${clientId}&redirect_uri=${encodeURIComponent(redirectUri)}&scope=${scope}&state=${state}&prompt=${prompt}|projects.oryapis.com/oauth2/auth?response_type=code&client_id=${clientId}&redirect_uri=${encodeURIComponent(redirectUri)}&scope=${scope}&state=${state}&prompt=${prompt}>`  // Redirect the user to the authorization URL window.location.href = authorizationUrl
Explanation: - The key part is adding 
&prompt=login
to the authorization URL. - When the user is redirected to this URL, Ory Hydra will require them to log in, even if they already have a session. Note: The Ory JavaScript SDK does not provide a helper for building the authorization URL; you construct it manually as shown above. The SDK is primarily used for interacting with the Ory APIs, not for the OAuth2 browser flow itself [Hydra JavaScript SDK](https://www.ory.sh/docs/hydra/sdk/js). For more details, see the [OAuth2 authorization code flow documentation](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow#examples). If you need to handle the token exchange after the user is redirected back, you can use 
fetch
as shown in the documentation example [OAuth2 authorization code flow examples](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow#examples).
i
@chilly-king-10285 ok, but this does not enforce it, i could still do this without prompt
b
A message from kapa.ai
You are correct: simply adding 
prompt=login
to the authorization URL will instruct Hydra to request a fresh login, but it does not enforce this on its own. If a client omits the 
prompt=login
parameter, and a valid session exists, Hydra (and your login provider) may allow the OAuth2 flow to proceed without requiring the user to re-authenticate. Enforcement must happen on the backend. If you want to always require credential verification for every OAuth2 flow—regardless of the 
prompt
parameter—you need to implement this logic in your login provider. The login provider is responsible for deciding whether to show the login UI or accept the session and skip login. Hydra itself relies on the login provider to enforce authentication requirements [Custom-login-consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow). In summary: - 
prompt=login
is a client-side hint, not an enforcement mechanism. - To truly enforce re-authentication, your login provider must always require credentials for OAuth2 flows, regardless of session state or the presence of 
prompt=login
. The knowledge sources do not describe a built-in Hydra configuration to force this behavior for all clients; it must be implemented in your login provider logic.
i
@chilly-king-10285 but ory is my login-provider, I can just protect the UI, cant i configure this per client e.g?
b
A message from kapa.ai
Based on the provided knowledge sources, there is no explicit configuration in Ory Hydra or Ory Kratos to enforce re-authentication (force credential entry) per OAuth2 client. The documentation describes that Hydra supports the 
prompt=login
parameter, which can be used by the client to request re-authentication, but this is a client-driven hint, not an enforcement mechanism from the server side [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). Ory Kratos (as the login provider) can protect the UI and implement logic to always require credential entry, but this would be a global behavior, not something that can be configured per OAuth2 client through Hydra or Kratos settings according to the available documentation. The login and consent flow is customizable, and you can implement your own logic in the login provider, but the knowledge sources do not mention a built-in per-client enforcement option [Custom-login-consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow). Summary: - You can protect the UI and always require credentials, but this is a global setting. - There is no documented way to configure this enforcement per OAuth2 client in Ory Hydra or Kratos. - Enforcement of credential entry must be implemented in your login provider logic, not via a Hydra or Kratos configuration option. If you need per-client enforcement, you would need to implement custom logic in your login provider to check the client ID and require credentials accordingly, but this is not described in the official documentation.
i
@chilly-king-10285 you can protect the UI and always require credentials, but this is a global setting. where is the global setting?
b
A message from kapa.ai
I'm sorry, but the knowledge sources do not mention a specific global configuration setting in Ory Hydra or Ory Kratos that enforces "always require credentials" for every login attempt, regardless of session state. The documentation describes how to use the 
prompt=login
parameter to force re-authentication, but this is controlled by the OAuth2 client, not by a global server-side setting [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). The knowledge sources also explain that the login provider (e.g., Ory Kratos) is responsible for handling authentication logic, and you can implement custom logic in your UI or backend to always require credentials. However, there is no documented global configuration option in Ory Kratos or Hydra to enforce this behavior automatically for all clients or flows [Custom-login-consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow). If you need this enforcement, you would need to implement it in your login provider logic, but the knowledge sources do not provide details or examples for such a setting.
i
@chilly-king-10285 how does prompt=true affect the behaviour can i see it in the api response?
b
A message from kapa.ai
The knowledge sources confirm that the 
prompt
parameter (such as 
prompt=login
) is supported in Ory Hydra's OAuth2 and OpenID Connect flows. When you include 
prompt=login
in the authorization request, it instructs the Authorization Server to prompt the user to log in, even if a session already exists. This means the user will be required to re-authenticate before the OAuth2 flow can proceed. However, the knowledge sources do not provide details about how the 
prompt
parameter is reflected in the API response. There is no explicit mention of a field in the API response that shows the value of 
prompt
or indicates that it was processed. The effect of 
prompt=login
is observed in the user experience: the login UI is shown regardless of session state, but this is not directly visible in the API response payload. In summary: - 
prompt=login
changes the flow by requiring user re-authentication. - The knowledge sources do not show a field in the API response that directly reflects the 
prompt
parameter or its effect. For more details, see the documentation on [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow).
i
@chilly-king-10285 how would the default UI behave if prompt=login is set with a valid session and how would it behave without it
b
A message from kapa.ai
If you use the default Ory UI and initiate an OAuth2 flow with a valid session: - With `prompt=login`: The user will always be shown the login screen and required to re-authenticate, even if they already have a valid session. This is because the 
prompt=login
parameter instructs the Authorization Server to force a login UI, regardless of session state [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). - Without `prompt=login`: If a valid session exists, the user will not be shown the login screen. Instead, the flow will proceed automatically, and the user will be redirected to the next step (such as consent or directly back to the client, depending on your configuration and whether consent is required) without any user interaction [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). Summary: - 
prompt=login
→ Login UI is always shown, user must re-authenticate. - No 
prompt=login
→ Login UI is skipped if session is valid, user is not prompted. This behavior is standard for Ory’s default UI and is described in the official documentation. If you need to enforce re-authentication in all cases, you must use 
prompt=login
in your OAuth2 requests [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow).
i
@chilly-king-10285 is that a save approach if the clients config decides if login is required or not?
b
A message from kapa.ai
No, it is not a fully secure approach to rely solely on the OAuth2 client’s configuration (such as using or omitting 
prompt=login
) to decide whether login is required. The knowledge sources make it clear that 
prompt=login
is a client-driven hint: it tells the Authorization Server to force a login, but if the client does not set this parameter and a valid session exists, the user will not be prompted to re-authenticate [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). This means that the client application controls whether the user is forced to log in again. If you have security requirements that always demand re-authentication (for example, for sensitive operations or high-assurance clients), you should not rely on the client to enforce this. Instead, you should implement this logic on the server side (in your login provider or authorization server), ensuring that re-authentication is enforced regardless of the client’s request. The knowledge sources do not describe a built-in way in Ory Hydra or Kratos to enforce this per client from the server side; it must be implemented in your backend logic [Custom-login-consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow). Summary: Letting the client decide if login is required is not a secure approach for scenarios where you must guarantee re-authentication. Server-side enforcement is necessary for strong security.
i
@chilly-king-10285 what is authentication method profile?
Copy code
export const SessionAuthenticationMethodMethodEnum = {
    Password: 'password',
    Oidc: 'oidc',
    Totp: 'totp',
    LookupSecret: 'lookup_secret',
    Webauthn: 'webauthn',
    Code: 'code',
    Passkey: 'passkey',
    Profile: 'profile',
    Saml: 'saml',
    LinkRecovery: 'link_recovery',
    CodeRecovery: 'code_recovery',
    UnknownDefaultOpenApi: '11184809'
} as const;
c
A message from kapa.ai
The knowledge sources do not provide a detailed explanation of the 
profile
authentication method. The available documentation lists 
profile
as one of the possible authentication methods that can appear in the session's 
authentication_methods
array, alongside others like 
password
, 
oidc
, 
totp
, etc. However, it does not describe what the 
profile
method specifically represents or when it is used in the authentication process [Kratos API Reference](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json). I'm sorry, but there's no information in the provided knowledge sources that explains the meaning or use case of the 
profile
authentication method.
i
@chilly-king-10285 i have an oauth client sending additional request params and hydra is answering with the following errror: .+Used+unknown+value+%27%5Bselect_account%5D%27+for+prompt+parameter what can i do?
c
A message from kapa.ai
The error message 
Used unknown value '[select_account]' for prompt parameter
indicates that the value you are sending for the 
prompt
parameter (
select_account
) is not recognized or supported by your Ory Hydra instance. According to the Ory documentation, the 
prompt
parameter in Hydra supports the following values: - 
none
- 
login
- 
consent
- 
registration
The value 
select_account
is not listed among the supported values in the knowledge sources. To resolve this error, you should only use the supported values for the 
prompt
parameter in your OAuth2 authorization requests [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). What you can do: - Remove 
select_account
from the 
prompt
parameter in your request. - Use only the supported values: 
none
, 
login
, 
consent
, or 
registration
. If you need functionality similar to 
select_account
, it is not supported out-of-the-box in Ory Hydra according to the current documentation.
i
@chilly-king-10285 but I dont have influcence on the params sent, they are automatically sent by the client i only can configure the connection through a ui panel
c
A message from kapa.ai
If you cannot control the parameters sent by the OAuth client and it automatically includes unsupported values like 
prompt=select_account
, Ory Hydra will reject the request with an error, as only 
none
, 
login
, 
consent
, and 
registration
are supported for the 
prompt
parameter [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). The knowledge sources do not mention a way to configure Hydra to ignore or accept unknown 
prompt
values, nor do they describe a workaround for this scenario. If you are limited to configuring the connection through a UI panel and cannot modify the client's behavior, you may encounter this limitation. Summary: - Hydra only supports specific 
prompt
values. - There is no documented way to allow unsupported 
prompt
values or to configure Hydra to ignore them. - If you cannot change the client's behavior, you may need to contact the client vendor or use a different client that allows you to control the sent parameters. I'm sorry, but the knowledge sources do not provide a solution for this scenario.
i
@chilly-king-10285 so you are saying me that ory is not compliant to openid specs? https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
c
A message from kapa.ai
Ory Hydra is a [Certified OpenID Connect Implementation](https://www.ory.sh/docs/oauth2-oidc#certified-openid-connect-implementation) and is listed as such by the OpenID Foundation. This means it has passed the official conformance tests for OpenID Connect and is compliant with the core specifications required for an OpenID Provider [Compliance and certifications](https://www.ory.sh/docs/security-compliance/compliance-and-certifications). However, not every optional feature or parameter in the OpenID Connect specification is necessarily supported by every certified implementation. The 
select_account
value for the 
prompt
parameter is defined in the OpenID Connect Core specification as a reserved value for future use, and its actual support is optional and not required for certification. According to the Ory documentation, Hydra supports the following 
prompt
values: 
none
, 
login
, 
consent
, and 
registration
 [OAuth2 authorization code flow](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow). The knowledge sources do not mention support for 
select_account
, and Hydra will return an error if it receives an unsupported value for 
prompt
. In summary: Ory Hydra is compliant with the OpenID Connect specification and is officially certified. The lack of support for 
prompt=select_account
does not mean it is non-compliant, as support for this value is not required for certification or core interoperability.
i
@chilly-king-10285 in my staging system my oauth clients are currently showing: {"errors":[{"status":"401","code":"SSO_LOGIN__INVALID_ID_TOKEN","title":"Unauthorized","detail":"The id token is invalid","meta":{"parameters":[]}}]} on trying to log in, but i dont know what, or who changed what, whats could be the root cause and how can i fix my staging system?
c
A message from kapa.ai
The error message 
SSO_LOGIN__INVALID_ID_TOKEN
with status 
401
indicates that the ID token provided during the SSO (Single Sign-On) login process is considered invalid by Ory. According to the knowledge sources, this can happen for several reasons, most commonly related to misconfiguration or changes in your identity provider or Ory project settings. Possible root causes include: - Token Audience Mismatch: If the audience (
aud
) claim in the ID token does not match what Ory expects, the token will be rejected. This can happen if the client ID or allowed audiences were changed in your Ory project or in the upstream identity provider configuration. Fix: Make sure your application's identifier is added to the 
additional_id_token_audiences
field or set as the Client ID of the provider in the Ory Console [Google social sign-in troubleshooting](https://www.ory.sh/docs/kratos/social-signin/google#troubleshooting). - Redirect URI Mismatch: If the redirect URI registered in Ory does not match the one used by the OAuth client, the ID token may be rejected. Fix: Double-check that the redirect URIs in your Ory project and your OAuth client configuration match exactly [Social sign-in troubleshooting](https://www.ory.sh/docs/kratos/social-signin/ory#troubleshooting). - Domain or Client Configuration Changes: If someone changed the domain, client ID, or secret in your staging system or in the upstream provider, this could invalidate tokens. - Upstream Identity Provider Issues: If the upstream provider (e.g., Google, Microsoft) changed its configuration, keys, or client settings, the tokens issued may no longer be valid for your Ory project. How to fix: 1. Review recent changes in your Ory Console and in your upstream identity provider (Google, Microsoft, etc.) for any modifications to client IDs, secrets, allowed audiences, or redirect URIs. 2. Check the Ory Console for the correct configuration of your social sign-in provider, especially the 
additional_id_token_audiences
and client ID fields. 3. Verify the redirect URIs are exactly matching between your Ory project and the OAuth client. 4. Consult the troubleshooting guides for social sign-in and ID token issues: - [Google social sign-in troubleshooting](https://www.ory.sh/docs/kratos/social-signin/google#troubleshooting) - [General social sign-in troubleshooting](https://www.ory.sh/docs/kratos/social-signin/ory#troubleshooting) If after these checks the issue persists, you may need to coordinate with your team to identify any recent changes in staging or consult the Ory logs for more detailed error information. Summary: The root cause is likely a misconfiguration or recent change in your Ory project or upstream identity provider. Focus on audience, client ID, and redirect URI settings to resolve the 
SSO_LOGIN__INVALID_ID_TOKEN
error.
3 Views
Open in Slack
PreviousNext
Powered by