famous-jackal-2829
05/26/2025, 9:37 AMbrief-egg-61061
05/26/2025, 9:37 AMbrief-egg-61061
05/26/2025, 9:38 AMemail
and profile
Make sure your OAuth2/OIDC client (Corteza) requests the email
and profile
scopes. These scopes are required for Hydra to request and return the email and profile claims from Kratos. Your callback URL shows scope=email+openid
, but you may also need profile
for additional user info. ### 2. Kratos Identity Schema Must Include Email Your Kratos identity schema must define the email
trait and mark it as required. From your config, it looks like you have this set up correctly: json "traits": { "email": { "type": "string", "format": "email", "<http://ory.sh/kratos|ory.sh/kratos>": { "credentials": { "password": { "identifier": true } }, "verification": { "via": "email" }, "recovery": { "via": "email" } } }, "name": { "type": "string", "title": "Nickname" } }, "required": ["email", "name"]
So as long as the user has a valid email, this should be fine. ### 3. Consent App Must Grant the Correct Scopes When Hydra redirects to your consent app, the consent app must grant the requested scopes (email
, profile
, openid
). If the consent app does not grant these, Hydra will not include them in the ID token or userinfo response. ### 4. Data Mapping and Claims Hydra will only return claims that are present in the identity and that are mapped to the requested scopes. If the email is missing from the identity, or if the mapping is not set up, the claim will not be present. Double-check that your Kratos identity has a valid, verified email and that the consent app is configured to allow the email
and profile
scopes. ### 5. Debugging Tips - Check the Hydra logs for any errors or warnings about missing claims or scopes. - Check the actual ID token and userinfo response returned by Hydra to see what claims are present. - Make sure the user in Kratos has a verified email if your client or consent app requires it. ### 6. Example: Common Pitfalls - If the user’s email is not verified and your system requires a verified email for login, the email claim may be omitted or empty. You can enforce email verification in Kratos as described in the docs: enable "Require Verified Address for Login" in the Ory Console or via config, and add the require_verified_address
hook to the login flow[Allow login only with verified email](https://www.ory.sh/docs/kratos/self-service/flows/verify-email-account-activation#allow-login-only-with-verified-email). - If the consent app does not grant the email
scope, Hydra will not return the email claim. ### 7. Configuration Checklist - Kratos identity schema: includes and requires email
. - Hydra client: requests openid email profile
scopes. - Consent app: grants openid email profile
scopes. - User: has a valid, verified email in Kratos. If all of the above are set up and you still do not receive the email, check the Hydra and Kratos logs for more details. If you can provide the Hydra logs for the authentication attempt, or the actual ID token/userinfo response, I can help you further debug the issue. --- Summary: The most common cause is missing or unverified email in the Kratos identity, or the consent app not granting the email
scope. Double-check your scopes, consent app, and user data in Kratos. If the problem persists, check the logs for more details and share them if you need more help. [Allow login only with verified email](https://www.ory.sh/docs/kratos/self-service/flows/verify-email-account-activation#allow-login-only-with-verified-email) [Social sign-in: Scopes and data mapping](https://www.ory.sh/docs/kratos/social-signin/ory#scopes) [GitLab Hydra integration troubleshooting](https://www.ory.sh/docs/hydra/self-hosted/gitlab#troubleshooting)famous-jackal-2829
05/26/2025, 9:40 AMbrief-egg-61061
05/26/2025, 9:41 AMbrief-egg-61061
05/26/2025, 9:41 AMjson { "traits": { "email": { "type": "string", "format": "email", "<http://ory.sh/kratos|ory.sh/kratos>": { "verification": { "via": "email" } } } } }
This tells Kratos to treat the email as a verifiable address [see docs](https://www.ory.sh/docs/kratos/self-service/flows/verify-email-account-activation#configuration). 2. Enable the Verification Flow In your Ory configuration, enable the verification flow and choose the method (code
or link
). For example: yaml selfservice: methods: code: enabled: true config: lifespan: 15m flows: verification: use: code enabled: true lifespan: 15m notify_unknown_recipients: false
Update your project configuration accordingly [see docs](https://www.ory.sh/docs/kratos/self-service/flows/verify-email-account-activation#configuration). 3. Trigger the Verification Flow After registration, Kratos will automatically send a verification email if verification is enabled. - The user receives an email with a code or link. - The user completes the verification by submitting the code or clicking the link. You can also manually trigger the verification flow by making a request to the verification endpoint: bash curl -X POST \ -H 'Content-Type: application/json' \ -H 'Accept: application/json' \ -d '{"method":"code","email":"<mailto:user@example.com|user@example.com>"}' \ "https://<your-project>.<http://projects.oryapis.com/self-service/verification?flow=<flow-id|projects.oryapis.com/self-service/verification?flow=<flow-id>>"
[Submit verification flow](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#submit-verification-flow) 4. Check Verification Status Once the user completes the verification, their identity will have the email marked as verified: json "verifiable_addresses": [ { "value": "<mailto:user@example.com|user@example.com>", "verified": true, "via": "email", "status": "completed" } ]
[Quickstart: Email verification](https://www.ory.sh/docs/kratos/quickstart#email-verification) Note: - Only one verification method (code
or link
) can be enabled at a time. - You can require verified email for login by enabling the "Require Verified Address for Login" option in the Ory Console or by adding the require_verified_address
hook to your login flow [see docs](https://www.ory.sh/docs/kratos/self-service/flows/verify-email-account-activation#allow-login-only-with-verified-email). For more details, see the [Ory Kratos email verification documentation](https://www.ory.sh/docs/kratos/self-service/flows/verify-email-account-activation).famous-jackal-2829
05/26/2025, 9:42 AMbrief-egg-61061
05/26/2025, 9:42 AMbrief-egg-61061
05/26/2025, 9:42 AMemail
trait as a string with email format and sets it as the identifier for password login. However, it does not mark the email as verifiable. To enable email verification in Ory Kratos, you need to add the verification
property under "<http://ory.sh/kratos|ory.sh/kratos>"
for the email
field. Here’s how you should update your schema: json { "$id": "<https://schemas.ory.sh/presets/kratos/quickstart/email-password/identity.schema.json>", "$schema": "<http://json-schema.org/draft-07/schema#>", "title": "Person", "type": "object", "properties": { "traits": { "type": "object", "properties": { "email": { "type": "string", "format": "email", "title": "email", "minLength": 6, "<http://ory.sh/kratos|ory.sh/kratos>": { "credentials": { "password": { "identifier": true } }, "verification": { "via": "email" } } } }, "required": [ "email" ], "additionalProperties": false } } }
This change tells Ory Kratos to treat the email as a verifiable address and will enable the email verification flow when users register or when you trigger verification manually. For more details, see the [Ory documentation on address verification](https://www.ory.sh/docs/kratos/self-service/flows/verify-email-account-activation#configuration) and [customizing the identity schema](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema#verification-address).famous-jackal-2829
05/26/2025, 10:01 AMbrief-egg-61061
05/26/2025, 10:01 AMbrief-egg-61061
05/26/2025, 10:01 AMui_url
for each flow in your Ory configuration. For example: yaml selfservice: flows: login: ui_url: <https://your-app.com/auth/login> registration: ui_url: <https://your-app.com/auth/registration>
This way, when a flow is initialized, Ory will redirect users to your client’s signup or login page, and your client will handle the UI and interact with Ory’s APIs to complete the flow. This approach is fully supported and is the recommended way to integrate Ory with custom applications [see docs](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#reference-implementations-and-examples). You can find reference implementations and more details in the documentation: - [Configure Ory to use your UI](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#reference-implementations-and-examples) - [Quickstart: Bring your own UI](https://www.ory.sh/docs/kratos/quickstart) So, your client app can act as the user interface for authentication, but Ory Kratos (or Ory Network) remains the actual identity provider and handles the identity management and authentication logic behind the scenes.famous-jackal-2829
05/26/2025, 10:02 AMbrief-egg-61061
05/26/2025, 10:02 AMbrief-egg-61061
05/26/2025, 10:02 AMui_url
fields in your Kratos configuration to point to your application's URLs for each self-service flow. For example, in your configuration: yaml selfservice: flows: login: ui_url: <http://127.0.0.1:4455/login> registration: ui_url: <http://127.0.0.1:4455/registration> settings: ui_url: <http://127.0.0.1:4455/settings> error: ui_url: <http://127.0.0.1:4455/error>
This tells Kratos to redirect users to your client app's pages for login, registration, settings, and error handling. Your client app will then render the UI and interact with Kratos' APIs to complete the authentication flows. This is the recommended approach for integrating your own UI with Ory Kratos [see docs](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui). So, yes—changing these ui_url
values to your client’s URLs is exactly how you make your client app the user interface for authentication, while Kratos remains the identity provider behind the scenes.famous-jackal-2829
05/26/2025, 10:10 AM[^-A-Za-z0-9+&@#/%?=~_|!:,.;\\(\\)]
)
stripSchema = regexp.MustCompile((.*\/\/)
)
BasePath string = "/"
WebappBasePath string = "/"
)
func GetLinks() Links {
var b = strings.TrimSuffix(BasePath, "/") + "/"
return Links{
Profile: b + "auth",
Signup: b + "auth/signup",
ConfirmEmail: b + "auth/confirm-email",
PendingEmailConfirmation: b + "auth/pending-email-confirmation",
Login: b + "auth/login",
Security: b + "auth/security",
ChangePassword: b + "auth/change-password",
CreatePassword: b + "auth/create-password",
RequestPasswordReset: b + "auth/request-password-reset",
PasswordResetRequested: b + "auth/password-reset-requested",
ResetPassword: b + "auth/reset-password",
AcceptInvite: b + "auth/accept-invite",
Sessions: b + "auth/sessions",
AuthorizedClients: b + "auth/authorized-clients",
Logout: b + "auth/logout",
OAuth2Authorize: b + "auth/oauth2/authorize",
OAuth2AuthorizeClient: b + "auth/oauth2/authorize-client",
OAuth2Token: b + "auth/oauth2/token",
OAuth2Info: b + "auth/oauth2/info",
OAuth2UserInfo: b + "auth/oauth2/userinfo",
OAuth2DefaultClient: b + "auth/oauth2/default-client",
OAuth2PublicKeys: b + "auth/oauth2/public-keys",
Mfa: b + "auth/mfa",
MfaTotpNewSecret: b + "auth/mfa/totp/setup",
MfaTotpQRImage: b + "auth/mfa/totp/qr.png",
MfaTotpDisable: b + "auth/mfa/totp/disable",
External: b + "auth/external",
SamlInit: b + "auth/external/saml/init",
SamlCallback: b + "auth/external/saml/callback",
SamlMetadata: b + "auth/external/saml/metadata",
SamlLogout: b + "auth/external/saml/slo",
Assets: b + "assets",
AuthAssets: b + "auth/assets/public",
Base: b,
}
}
// trim base path
func tbp(s string) string {
s = strings.TrimPrefix(s, BasePath)
if !strings.HasPrefix(s, "/") {
s = "/" + s
}
return s
}
func sanitizeLink(l string) string {
return //
+ stripSchema.ReplaceAllString(invalidLinkChars.ReplaceAllString(l, ""), "")
}brief-egg-61061
05/26/2025, 10:10 AMbrief-egg-61061
05/26/2025, 10:10 AMLinks
struct and the way your client application defines its authentication-related routes (e.g., /auth/login
, /auth/signup
, etc.), you can absolutely use these endpoints as the UI URLs for Ory Kratos self-service flows. To do this, you need to configure your Kratos kratos.yml
(or equivalent config) so that the ui_url
for each flow points to the corresponding route in your client. For example: yaml selfservice: flows: login: ui_url: <http://your-client-domain/auth/login> registration: ui_url: <http://your-client-domain/auth/signup> settings: ui_url: <http://your-client-domain/auth/security> error: ui_url: <http://your-client-domain/auth/error>
This setup tells Ory Kratos to redirect users to your client’s pages for login, signup, settings, and error handling. Your client app will then render the UI and interact with Kratos’ APIs to complete the authentication flows. This is the recommended and supported approach for integrating your own UI with Ory Kratos [Configure Ory to use your UI](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui). Summary: Yes, you can use your client’s signup and login pages as the default UI for Ory Kratos by setting the appropriate ui_url
values in your Kratos configuration to match your client’s routes. Kratos will remain the identity provider, while your client provides the user interface. If you need more details on how to connect your UI to Ory Kratos flows, see the [integration basics documentation](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration).famous-jackal-2829
05/26/2025, 10:12 AMbrief-egg-61061
05/26/2025, 10:12 AMbrief-egg-61061
05/26/2025, 10:12 AM/auth/login
, /auth/signup
, /auth/security
, etc.), here’s how you should update your Kratos configuration to use your client as the UI for all self-service flows: yaml version: v1.1.0 dsn: memory serve: public: base_url: <http://127.0.0.1:4433> cors: enabled: true admin: base_url: <http://127.0.0.1:4434> selfservice: default_browser_return_url: <http://127.0.0.1:4455/auth/> allowed_return_urls: - <http://127.0.0.1:4455> methods: password: enabled: true config: min_password_length: 6 identifier_similarity_check_enabled: false haveibeenpwned_enabled: false flows: error: ui_url: <http://127.0.0.1:4455/auth/error> settings: ui_url: <http://127.0.0.1:4455/auth/security> privileged_session_max_age: 15m required_aal: highest_available logout: after: default_browser_return_url: <http://127.0.0.1:4455/auth/login> login: ui_url: <http://127.0.0.1:4455/auth/login> registration: ui_url: <http://127.0.0.1:4455/auth/signup> after: password: hooks: - hook: session log: format: text leak_sensitive_values: true level: info secrets: cookie: - CHANGE_ME_TO_REAL_SECRET cipher: - 32-LONG-SECRET-NOT-SECURE-AT-ALL identity: default_schema_id: default schemas: - id: default url: file:///etc/config/kratos/identity.schema.json # Important: identity schema courier: smtp: connection_uri: <smtps://test:test@mailslurper:1025/?skip_ssl_verify=true> oauth2_provider: url: <http://hydra:4445> # Important: hydra admin URL
Key changes: - All ui_url
values now point to your client’s /auth/...
routes, matching your handler definitions. - The default_browser_return_url
is set to your client’s /auth/
base path. This configuration ensures Ory Kratos will redirect users to your client’s pages for all self-service flows, as described in the official documentation [Configure Ory to use your UI](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui). If you need to adjust for other routes (e.g., password reset, email confirmation), you can add or update the corresponding ui_url
values as needed.famous-jackal-2829
05/26/2025, 3:34 PMbrief-egg-61061
05/26/2025, 3:34 PMbrief-egg-61061
05/26/2025, 3:34 PM91.107.176.143
, you need to update your configuration files to use this public IP (or your domain name, if you have one) instead of localhost
or 127.0.0.1
. Here are the main things you should change, based on the official deployment guides: --- ### 1. Update Base URLs in Configuration For both Ory Kratos and Ory Hydra, update the base_url
, issuer
, and all relevant URLs to use <http://91.107.176.143>
(or <https://91.107.176.143>
if you use TLS): Ory Kratos Example: yaml serve: public: base_url: <http://91.107.176.143:4433/> admin: base_url: <http://91.107.176.143:4434/>
Update all ui_url
and default_browser_return_url
values to use your server IP: yaml selfservice: default_browser_return_url: <http://91.107.176.143/auth/> allowed_return_urls: - <http://91.107.176.143> flows: login: ui_url: <http://91.107.176.143/auth/login> registration: ui_url: <http://91.107.176.143/auth/signup> # ...and so on
[See: Deploy to production – Configure User Interface](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#configure-user-interface) --- Ory Hydra Example: yaml urls: self: issuer: <http://91.107.176.143:4444> consent: <http://91.107.176.143:9020/consent> login: <http://91.107.176.143:9020/login>
[See: Install Ory Hydra](https://www.ory.sh/docs/hydra/self-hosted/deploy-hydra-example#install-ory-hydra) --- ### 2. DNS and Reverse Proxy - If you have a domain, point your DNS records to 91.107.176.143
. - If you use Nginx or another reverse proxy, update its configuration to listen on the public IP and proxy to the correct internal ports. - Make sure to secure your endpoints (especially admin APIs) and do not expose them to the public internet without proper protection [see: Run Ory Kratos using systemd](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#run-ory-kratos-using-systemd). --- ### 3. Consent/Login UI - Update the consent/login UI configuration to use the public IP for any callbacks or API calls to Kratos or Hydra. --- ### 4. Firewall and Ports - Open the necessary ports (e.g., 4433, 4434, 4444, 4445, 9020) in your server’s firewall to allow external access. --- ### 5. Environment Variables - If you use Docker or systemd, update any environment variables that reference localhost
or 127.0.0.1
to use 91.107.176.143
. --- ### 6. Security - For production, use HTTPS (TLS) for all public endpoints. - Never expose the admin APIs to the public internet without proper security controls. --- Summary: Replace all instances of localhost
or 127.0.0.1
in your configuration files and environment variables with your server’s public IP (91.107.176.143
). Update your DNS and reverse proxy as needed, and ensure your firewall allows the required ports. For production, always use HTTPS and secure your admin APIs. If you need more specific examples for your setup, let me know which service or config you want to see!famous-jackal-2829
05/26/2025, 3:35 PMbrief-egg-61061
05/26/2025, 3:35 PMbrief-egg-61061
05/26/2025, 3:36 PM91.107.176.143
, you need to update your configuration files so that all service URLs, callback URLs, and public endpoints reference this IP instead of localhost
or 127.0.0.1
. Here’s how you should approach the changes, based on the knowledge sources: --- ### 1. docker-compose.yml - Update all service environment variables and ports to use the public IP where necessary. - Ensure that the services are accessible on the correct ports from outside the server. Example (relevant parts only): yaml services: kratos: image: oryd/kratos:v1.3.1 ports: - '4433:4433' # public - '4434:4434' # admin environment: - DSN=<postgres://kratos:secret@postgresd:5432/kratos?sslmode=disable> # ... other config hydra: image: oryd/hydra:v2.2.0 ports: - "4444:4444" # Public port - "4445:4445" # Admin port environment: - DSN=<postgres://kratos:secret@postgresd:5432/hydra?sslmode=disable> # ... other config consent-ui: # Your consent UI service ports: - "9020:9020" # ... other config
Note: The actual IP binding is typically handled by Docker’s networking, but your service URLs in the config files must reference the public IP. --- ### 2. hydra.yml Update all URLs to use your public IP: yaml urls: self: issuer: <http://91.107.176.143:4444> public: <http://91.107.176.143:4444> admin: <http://91.107.176.143:4445> consent: <http://91.107.176.143:9020/consent> login: <http://91.107.176.143:9020/login> logout: <http://91.107.176.143:9020/logout> identity_provider: url: <http://91.107.176.143:4434/> publicUrl: <http://91.107.176.143:4433/>
This ensures that Hydra knows where to redirect users and where to reach Kratos and the consent app. [See: Deploy Ory Hydra](https://www.ory.sh/docs/hydra/self-hosted/configure-deploy#deploy-ory-hydra) --- ### 3. kratos.yml Update all UI URLs and base URLs to use your public IP: yaml serve: public: base_url: <http://91.107.176.143:4433/> admin: base_url: <http://91.107.176.143:4434/> selfservice: default_browser_return_url: <http://91.107.176.143/auth/> allowed_return_urls: - <http://91.107.176.143> flows: login: ui_url: <http://91.107.176.143/auth/login> registration: ui_url: <http://91.107.176.143/auth/signup> settings: ui_url: <http://91.107.176.143/auth/security> error: ui_url: <http://91.107.176.143/auth/error> oauth2_provider: url: <http://91.107.176.143:4445>
[See: Configure User Interface](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#configure-user-interface) --- Important Notes: - If you have a domain name, use it instead of the raw IP for better security and user experience. - For production, you should use HTTPS and secure your admin endpoints. The knowledge sources recommend not exposing admin APIs to the public internet and using a reverse proxy or API gateway for additional security [see: Go to production](https://www.ory.sh/docs/kratos/guides/production). - Open the necessary ports in your firewall to allow external access to these services. If you need more specific examples or have a particular use case, please provide more details about your consent UI or other services.famous-jackal-2829
05/26/2025, 3:38 PMbrief-egg-61061
05/26/2025, 3:38 PMbrief-egg-61061
05/26/2025, 3:39 PM91.107.176.143
. All relevant URLs and service endpoints have been updated to use this IP, as recommended in the Ory documentation for production deployments [see docs](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#configure-user-interface). --- ### docker-compose.yml yaml version: '3.7' services: hydra-postgres: image: postgres:15 environment: POSTGRES_DB: hydra POSTGRES_USER: hydra POSTGRES_PASSWORD: secret ports: - "5430:5432" volumes: - hydra_postgres_data:/var/lib/postgresql/data networks: - intranet restart: unless-stopped kratos-postgres: image: postgres:15 environment: POSTGRES_DB: kratos POSTGRES_USER: kratos POSTGRES_PASSWORD: secret ports: - "5431:5432" volumes: - kratos_postgres_data:/var/lib/postgresql/data networks: - intranet restart: unless-stopped hydra-migrate: image: oryd/hydra:latest environment: - DSN=<postgres://hydra:secret@hydra-postgres:5432/hydra?sslmode=disable> command: migrate -c /etc/config/hydra/hydra.yml sql -e --yes volumes: - ./config:/etc/config/hydra restart: on-failure depends_on: - hydra-postgres networks: - intranet hydra: image: oryd/hydra:latest ports: - "4444:4444" # Public port - "4445:4445" # Admin port - "5555:5555" # Port for hydra token user volumes: - ./config:/etc/config/hydra environment: - DSN=<postgres://hydra:secret@hydra-postgres:5432/hydra?sslmode=disable> command: serve -c /etc/config/hydra/hydra.yml all --dev restart: unless-stopped depends_on: - hydra-migrate - hydra-postgres networks: - intranet kratos-migrate: image: oryd/kratos:latest environment: - DSN=<postgres://kratos:secret@kratos-postgres:5432/kratos?sslmode=disable> volumes: - ./config:/etc/config/kratos command: -c /etc/config/kratos/kratos.yml migrate sql -e --yes restart: on-failure depends_on: - kratos-postgres networks: - intranet kratos: depends_on: - kratos-migrate - kratos-postgres image: oryd/kratos:latest ports: - '4433:4433' # public - '4434:4434' # admin restart: unless-stopped environment: - DSN=<postgres://kratos:secret@kratos-postgres:5432/kratos?sslmode=disable> command: serve -c /etc/config/kratos/kratos.yml --dev --watch-courier volumes: - ./config:/etc/config/kratos networks: - intranet kratos-selfservice-ui-node: image: oryd/kratos-selfservice-ui-node:latest ports: - "4455:4455" environment: - KRATOS_PUBLIC_URL=<http://91.107.176.143:4433/> - KRATOS_BROWSER_URL=<http://91.107.176.143:4433/> - HYDRA_ADMIN_URL=<http://91.107.176.143:4445> - PORT=4455 - COOKIE_SECRET=SuperSecretCookie - CSRF_COOKIE_NAME=__OryKratosApp - CSRF_COOKIE_SECRET=SuperSecretCookieCsrf networks: - intranet restart: on-failure mailslurper: image: oryd/mailslurper:latest-smtps ports: - '4436:4436' - '4437:4437' networks: - intranet networks: intranet: volumes: hydra_postgres_data: kratos_postgres_data:
--- ### hydra.yml yaml serve: cookies: same_site_mode: Lax public: cors: enabled: true allowed_origins: - <http://91.107.176.143>* allowed_methods: - POST - GET - PUT - PATCH - DELETE allowed_headers: - Authorization exposed_headers: - Content-Type admin: cors: enabled: true allowed_origins: - <http://91.107.176.143>* allowed_methods: - GET - POST - OPTIONS allowed_headers: - Content-Type exposed_headers: - Content-Type urls: self: issuer: <http://91.107.176.143:4444> consent: <http://91.107.176.143:4455/consent> login: <http://91.107.176.143:4455/login> logout: <http://91.107.176.143:4455/logout> identity_provider: url: <http://91.107.176.143:4434> secrets: system: - CHANGE_ME_TO_REAL_SECRET oidc: subject_identifiers: supported_types: - pairwise - public pairwise: salt: CHANGE_ME_TO_REAL_SECRET log: leak_sensitive_values: true level: info
--- ### kratos.yml yaml version: v1.1.0 dsn: <postgres://kratos:secret@kratos-postgres:5432/kratos?sslmode=disable> serve: public: base_url: <http://91.107.176.143:4433> cors: enabled: true admin: base_url: <http://91.107.176.143:4434> selfservice: default_browser_return_url: <http://91.107.176.143:4455/> allowed_return_urls: - <http://91.107.176.143:4455> methods: password: enabled: true config: min_password_length: 6 identifier_similarity_check_enabled: false haveibeenpwned_enabled: false flows: error: ui_url: <http://91.107.176.143:4455/error> settings: ui_url: <http://91.107.176.143:4455/settings> privileged_session_max_age: 15m required_aal: highest_available logout: after: default_browser_return_url: <http://91.107.176.143:4455/login> login: ui_url: <http://91.107.176.143:4455/login> registration: ui_url: <http://91.107.176.143:4455/registration> after: password: hooks: - hook: session log: format: text leak_sensitive_values: true level: info secrets: cookie: - CHANGE_ME_TO_REAL_SECRET cipher: - 32-LONG-SECRET-NOT-SECURE-AT-ALL identity: default_schema_id: default schemas: - id: default url: file:///etc/config/kratos/identity.schema.json courier: smtp: connection_uri: <smtps://test:test@mailslurper:1025/?skip_ssl_verify=true> oauth2_provider: url: <http://91.107.176.143:4445>
--- Notes: - Replace CHANGE_ME_TO_REAL_SECRET
with strong, secure secrets in production. - For production, you should use HTTPS and secure your admin endpoints as recommended in the Ory documentation. - Make sure your firewall allows the necessary ports (4433, 4434, 4444, 4445, 4455, etc.) to be accessed externally. If you need to use a domain name instead of the IP, simply replace 91.107.176.143
with your domain throughout the configs. If you need further customization or run into issues, please provide more details about your setup.famous-jackal-2829
05/28/2025, 10:11 AMbrief-egg-61061
05/28/2025, 10:11 AMbrief-egg-61061
05/28/2025, 10:12 AMThe requested page could not be found (404)
) at the URL <https://rc.qaap.io/auth/self-service/login/sessions>
suggests that the route does not exist in your Kratos Self-Service UI or is not handled by your application. Key points from the knowledge sources: 1. Kratos Self-Service UI Endpoints The Kratos self-service flows (login, registration, etc.) expect your UI to handle specific routes such as /auth/login
, /auth/registration
, /auth/settings
, etc. There is no default /auth/self-service/login/sessions
route in the standard Kratos UI or in the documented flows. This path is likely incorrect or not implemented in your UI or reverse proxy configuration [see: Bring your own UI](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui). 2. UI URL Configuration In your kratos.yml
, you have: yaml selfservice: flows: login: ui_url: <https://rc.qaap.io/auth/login>
This means Kratos will redirect to /auth/login
for the login UI, not /auth/self-service/login/sessions
. 3. Reverse Proxy (Nginx) or Routing If you are using Nginx or another reverse proxy, ensure that it is routing requests for /auth/login
, /auth/registration
, etc., to your UI service and not to Kratos directly. If you want to share your Nginx configuration, I can help review it for issues. 4. Allowed Return URLs Your allowed_return_urls
and default_browser_return_url
are set to <https://rc.qaap.io/auth>
and <https://rc.qaap.io>
, which is correct as long as your UI is available at those paths. 5. Hydra and Kratos Integration Your Hydra and Kratos configurations reference the correct public URLs, but make sure that the consent and login URLs in Hydra (hydra.yml
) match the actual routes implemented in your UI. --- ### What to Check and Fix - UI Implementation: Make sure your UI (or the Kratos Self-Service UI Node) implements the /auth/login
route and not /auth/self-service/login/sessions
. - Nginx/Proxy Configuration: Ensure that requests to /auth/login
are routed to your UI, not to Kratos' public API. - Do Not Use /self-service/login/sessions
as a UI Route: This is not a standard UI endpoint and will result in a 404 unless you have specifically implemented it. --- If you want to share your Nginx configuration, I can review it for potential routing issues that might be causing this 404 error. Summary: The 404 is likely because /auth/self-service/login/sessions
is not a valid or implemented route in your UI. Double-check your UI and proxy configuration to ensure only the documented self-service UI routes (like /auth/login
, /auth/registration
, etc.) are used and properly routed [see: Bring your own UI](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui). If you need help with your Nginx config, please provide it.famous-jackal-2829
05/28/2025, 10:13 AMbrief-egg-61061
05/28/2025, 10:14 AMbrief-egg-61061
05/28/2025, 10:14 AM404 - Page not found
at /auth/self-service/login/sessions
), here are some important points and suggestions: --- ### 1. UI Routing and Proxying Your Nginx config correctly proxies /auth/*
to the Kratos Self-Service UI Node (ui_node
). The rewrite rule: nginx location /auth { rewrite /auth/(.*) /$1 break; proxy_pass <http://ui_node>; ... }
This means a request to /auth/login
will be proxied to the UI Node as /login
, which matches the expected route for the Kratos UI. This is correct and matches the [Ory documentation for custom UIs](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#configure-user-interface). --- ### 2. 404 on /auth/self-service/login/sessions
The path /auth/self-service/login/sessions
is not a standard Kratos Self-Service UI route. The expected UI routes are /auth/login
, /auth/registration
, /auth/settings
, etc. If your application or a redirect is trying to access /auth/self-service/login/sessions
, it will result in a 404 unless your UI Node or app implements this route, which is not standard. - Action: Check your Kratos UI, Hydra consent app, and any client applications to ensure they are using the correct UI URLs (e.g., /auth/login
for login, not /auth/self-service/login/sessions
). Your Kratos config should have: yaml selfservice: flows: login: ui_url: <https://rc.qaap.io/auth/login> registration: ui_url: <https://rc.qaap.io/auth/registration> # etc.
This matches your Nginx routing. --- ### 3. Proxying Kratos Public and Admin APIs Your config for proxying /
to the Kratos public API and /admin
to the admin API is correct and matches the [Ory production deployment guide](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#install-and-configure-nginx). --- ### 4. Allowed Return URLs Your Kratos config should include the correct allowed return URLs, matching your domain and UI paths, which you have done. --- ### 5. SSL and Server Names You are using SSL and have set up server names for each subdomain, which is correct. --- ### 6. Summary of the Issue - The 404 is caused by a request to a non-existent route: /auth/self-service/login/sessions
. - The correct UI routes are /auth/login
, /auth/registration
, etc. - Ensure all Ory config (ui_url
, default_browser_return_url
, etc.) and client apps use these correct routes. - Your Nginx config is correct for these routes. --- If you continue to see 404s, check: - The actual URLs being generated by your apps and Ory config. - That your UI Node is running and accessible at the expected port. - That no other proxy or app is interfering with these routes. If you need more help, please provide the exact URL that triggers the 404 and clarify which app or flow is generating it. --- In summary: Your Nginx config is correct for standard Ory Kratos and UI integration. The 404 is likely due to a misconfigured route in your app or Ory config, not the Nginx proxy itself. Make sure all flows use the documented UI endpoints (e.g., /auth/login
) and not /auth/self-service/login/sessions
[see docs](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#configure-user-interface).famous-jackal-2829
05/28/2025, 10:16 AMbrief-egg-61061
05/28/2025, 10:16 AMbrief-egg-61061
05/28/2025, 10:17 AM<https://rc.qaap.io/auth>
. The ui_url
values for login, registration, settings, and error all point to your client’s routes, which matches the recommended approach for integrating your own UI with Ory Kratos [Configure Ory to use your UI](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui). Key points from your config: - base_url
for public and admin endpoints is set to your domain. - All self-service flow UI URLs (login
, registration
, settings
, error
) are set to your client’s /auth/...
routes. - default_browser_return_url
and allowed_return_urls
are set to your domain and UI path. - The password method is enabled and configured. - The identity schema is referenced correctly. What to check if you still encounter issues: - Make sure your UI (at /auth/login
, /auth/registration
, etc.) is running and accessible. - Ensure your Nginx or reverse proxy is routing /auth/*
requests to your UI service, not directly to Kratos. - The Kratos public API should not be exposed directly to end users; only your UI should interact with it. - If you see 404 errors for routes like /auth/self-service/login/sessions
, verify that your UI and Ory config are not generating or expecting non-standard routes. The standard UI routes are /auth/login
, /auth/registration
, etc. [see docs](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#configure-user-interface). If you have a specific error or behavior you want reviewed, please provide the exact error message and the URL that triggers it. Otherwise, your configuration matches the documented best practices for Ory Kratos with a custom UI.famous-jackal-2829
05/28/2025, 10:20 AMbrief-egg-61061
05/28/2025, 10:20 AMbrief-egg-61061
05/28/2025, 10:20 AM/self-service
part in /auth/self-service/login/sessions
comes from Ory Kratos' API endpoints for self-service flows. In Ory Kratos, all self-service operations (such as login, registration, settings, recovery, etc.) are exposed under the /self-service
path in the public API. For example: - /self-service/login/browser
- /self-service/registration/browser
- /self-service/settings/browser
- /self-service/recovery/browser
These endpoints are meant to be called by your application's backend or frontend to initialize and manage authentication-related flows [see: Self-service flows overview](https://www.ory.sh/docs/kratos/self-service#browser-flows-for-server-side-apps-nodejs-php-java-). However, the /self-service
path is not intended to be part of your UI routes. Your UI should expose routes like /auth/login
, /auth/registration
, etc., and interact with the Kratos API at /self-service/...
behind the scenes. If you see a route like /auth/self-service/login/sessions
in your browser, it likely means that either: - Your UI is incorrectly exposing or redirecting to an internal Kratos API path, or - There is a misconfiguration in your routing or reverse proxy setup that is forwarding API paths to your UI. In summary, /self-service
is the prefix for Kratos' API endpoints, not for UI routes. Your UI should not expose or redirect users to /auth/self-service/...
paths [see: Bring your own UI](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui). If you are seeing this in your application, check your UI and proxy configuration to ensure only the correct UI routes are exposed to users.brief-egg-61061
05/28/2025, 10:21 AMbrief-egg-61061
05/28/2025, 10:21 AM/self-service
part in /auth/self-service/login/sessions
originates from Ory Kratos' API endpoints, which are used for self-service flows such as login, registration, settings, and recovery. These API endpoints are documented as being under the /self-service
path, for example: - /self-service/login/browser
- /self-service/registration/browser
- /self-service/settings/browser
These endpoints are intended for API calls, not for direct user-facing UI routes. The UI routes you configure for users (such as /auth/login
or /auth/registration
) should be separate and are set using the ui_url
configuration in Kratos. If you are seeing /auth/self-service/login/sessions
in your browser, it likely means that either your UI or reverse proxy is incorrectly exposing or redirecting to an internal Kratos API path, rather than the intended UI route [Integration basics](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration). In summary, /self-service
is the prefix for Kratos' self-service API endpoints, not for UI routes. If you see it in your browser's address bar, it is likely due to a misconfiguration in your application's routing or proxy setup.