Ory Kratos and Ory Hydra are two separate components of the Ory ecosystem, each serving a different purpose. Ory Kratos is an identity management server that handles user management, login, registration, and other identity-related tasks in a secure and straightforward way. It implements all common flows such as login and logout, account activation, multi-factor authentication, profile and session management, user-facing errors, and account recovery methods. It does not ship with an HTML rendering engine, meaning you have to implement the user interface yourself or use the Ory Account Experience available in Ory Network[^1^][^4^]. On the other hand, Ory Hydra is an OAuth 2.0 and OpenID Connect provider. It does not handle user management but instead delegates these tasks to your own application or a service like Ory Kratos. When an OAuth2 request is initiated, Hydra needs to know which user is giving consent. To determine this, Hydra redirects the user agent (browser, mobile device) to your application's login endpoint. Upon successful authentication, the login endpoint redirects the user back to Ory Hydra[^5^]. In terms of how Hydra knows if a user is valid, it relies on your application's login endpoint to authenticate the user. Once the user is authenticated, your application redirects the user back to Hydra with the necessary information[^5^]. As for the communication between Kratos and Hydra, there isn't a direct interaction between the two in the extracts provided. However, one of the extracts suggests an alternative to callback and custom code is fronting the legacy system with Ory OAuth2 & OpenID Connect (Ory Hydra) and then using that as an upstream in Ory Identities (Ory Kratos)[^6^]. This suggests that Hydra can be used as an intermediary for handling OAuth2 & OpenID Connect protocols, while Kratos manages the identities. [^1^]: [Ory Kratos Introduction](https://www.ory.sh/docs/ecosystem/projects) [^4^]: [Introduction to Ory Identities (Ory Kratos)](https://www.ory.sh/docs/kratos/ory-kratos-intro) [^5^]: [Ory Hydra Case Study](https://www.ory.sh/docs/hydra/case-study) [^6^]: [General Troubleshooting](https://www.ory.sh/docs/kratos/debug/troubleshooting)

For native applications, you should use the API flows which don't set any cookies. The response from these flows contains all the data required to render the UI. On successful login, Ory issues a session token that can be used to authenticate subsequent requests to Ory[^7^]. In the case of Ory Hydra, it's important to note that it doesn't contain a database with end users but instead uses HTTP redirection to "delegate" the login flow to another app[^3^]. However, you can customize Ory OAuth2 and OpenID Connect to work with your user database, login UI, and consent logic and UI[^3^]. For example, you can authenticate the user as usual at your login endpoint (for example by username & password, session cookie or other means). Upon successful authentication, instead of redirecting the user back to Ory Hydra, you can make a direct API call to Ory Hydra to validate the request and issue the access, refresh, and ID tokens[^2^]. You can also validate the access tokens which are sent to your API directly at Ory Hydra, or use an Identity & Access Proxy like Ory Oathkeeper to do it for you[^2^]. For more detailed instructions and examples, you can refer to the [Node.js implementation of an app that implements custom login and consent on Ory's GitHub](https://github.com/ory/hydra-login-consent-node)[^3^]. [^2^]: [Ory Hydra Case Study](https://www.ory.sh/docs/hydra/case-study) [^3^]: [User login and consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow) [^7^]: [Integration basics for Native application](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration)

Ory Hydra doesn't handle user authentication itself. Instead, it relies on your application's login endpoint to authenticate the user. Once the user is authenticated, your application redirects the user back to Hydra with the necessary information[^5^]. In terms of security, Ory Hydra follows several principles to ensure the safety of the tokens it issues. These principles include encryption of credentials, use of short expiration time, automatic revocation of derived tokens if abuse is detected, binding of refresh token to "client_id", refresh token rotation, revocation of refresh tokens, and use of asymmetric cryptography[^6^]. For token validation, Ory Hydra uses advanced token validation. Tokens are laid out as <key>.<signature> where <signature> is created using HMAC-SHA256 using a global secret. For an OAuth2 access token, refresh token, or authorize code to be valid, one requires both the key and the signature. Only the signature is stored in the data store (SQL), thus a compromised datastore won't allow an attacker to gain access to any valid authorize codes, access tokens, or refresh tokens[^6^]. In the case of Ory Kratos, the validity of a session token can be checked at the

<http://127.0.0.1/sessions/whoami>

endpoint[^4^]. If the

Authorization: bearer <ory-session-token>

HTTP header was set with a valid Ory Kratos Session Token, the endpoint authenticates the user[^3^]. [^3^]: [Ory API Reference](https://www.ory.sh/docs/reference/api) [^4^]: [User login API clients](https://www.ory.sh/docs/kratos/self-service/flows/user-login) [^5^]: [Ory Hydra Case Study](https://www.ory.sh/docs/hydra/case-study) [^6^]: [OAuth 2.0 security overview](https://www.ory.sh/docs/hydra/security-architecture)

Ory Hydra doesn't generate tokens based solely on redirection. The redirection is part of the OAuth 2.0 and OpenID Connect flows, which are designed to securely handle authentication and authorization between multiple parties. When a client initiates an OAuth2 request, Hydra creates a challenge and redirects the user to your application's login endpoint. Your application is responsible for authenticating the user. Upon successful authentication, your application redirects the user back to Hydra with the challenge and additional information about the user's authentication status[^5^]. Hydra then validates the challenge and the authentication information. If everything checks out, Hydra proceeds to the consent flow, which involves asking the user to grant the client access to their resources. Once the user gives consent, Hydra issues the access, refresh, and ID tokens[^5^]. The tokens issued by Hydra are secure. They are laid out as <key>.<signature> where <signature> is created using HMAC-SHA256 with a global secret. Only the signature is stored in the data store (SQL), thus a compromised datastore won't allow an attacker to gain access to any valid authorize codes, access tokens, or refresh tokens[^6^]. In other words, even though the flow involves redirection, the process of issuing tokens is secure and involves multiple checks and validations. It's not possible for anyone to generate valid tokens without going through the entire flow and without having access to the global secret used for creating the signatures[^6^]. [^5^]: [Ory Hydra Case Study](https://www.ory.sh/docs/hydra/case-study) [^6^]: [OAuth 2.0 security overview](https://www.ory.sh/docs/hydra/security-architecture)