Certainly! Here’s a step-by-step technical flow for a Single Page Application (SPA) that uses Ory Kratos for user signup and login, and Ory Hydra for obtaining OAuth2/OIDC tokens. This flow is based on the integration of Kratos (identity provider) and Hydra (OAuth2/OIDC provider), as described in the provided knowledge sources. --- ## 1. User Signup in SPA via Kratos a. SPA initiates the registration flow: - The SPA sends an AJAX request to Kratos to initialize the registration flow:

GET /self-service/registration/browser   Accept: application/json

Kratos responds with a flow object containing a unique flow ID and form fields for registration (e.g., email, password, etc.)[Browser flows for client-side apps](https://www.ory.sh/docs/kratos/self-service#browser-flows-for-client-side-apps-single-page-apps-reactjs-angular-nextjs-). b. SPA renders the registration form: - The SPA displays the registration form using the data from the flow object. c. User submits the registration form: - The SPA submits the registration data to Kratos:

POST /self-service/registration?flow=<flow_id>   Content-Type: application/json

Kratos processes the registration and, if successful, can be configured to automatically log the user in (see next step)[Self-service flows](https://www.ory.sh/docs/kratos/self-service). --- ## 2. Automatic Login After Signup - Kratos supports running hooks after registration, such as the

session

hook, which automatically creates a session for the user upon successful registration. This means the user is immediately logged in after signup, and a session cookie is set in the browser[Self-service flows](https://www.ory.sh/docs/kratos/self-service). --- ## 3. Obtaining Access and ID Tokens from Hydra a. SPA initiates the OAuth2 Authorization Code flow: - The SPA redirects the user’s browser to Hydra’s

/oauth2/auth

endpoint, including parameters such as

client_id

,

redirect_uri

,

scope

, and `response_type=code`:

GET /oauth2/auth?client_id=...&redirect_uri=...&scope=openid&response_type=code&state=...

b. Hydra checks for an active session: - If the user has a valid Kratos session (from the previous step), Hydra recognizes the session and may skip the login step. If not, Hydra redirects to the login provider (Kratos) for authentication[Custom login and consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#flow-steps). c. Consent screen (if required): - Hydra may redirect the user to a consent screen, depending on your configuration. The user grants consent, and Hydra continues the flow. d. Hydra issues an authorization code: - After successful login and consent, Hydra redirects the user back to the SPA’s

redirect_uri

with an authorization code:

GET /callback?code=<authorization_code>&state=...

e. SPA exchanges the code for tokens: - The SPA sends a POST request to Hydra’s token endpoint to exchange the authorization code for access and ID tokens:

POST /oauth2/token   grant_type=authorization_code   code=<authorization_code>   redirect_uri=<redirect_uri>   client_id=<client_id>   client_secret=<client_secret>

Hydra responds with the access token and ID token. --- ## Key Points - Session Handling: Kratos manages the user session via cookies. Hydra checks for this session to determine if the user is authenticated. - Redirection Logic: The SPA coordinates redirections between Kratos (for registration/login) and Hydra (for OAuth2 authorization and token exchange). - Endpoints Involved: - Kratos:

/self-service/registration/browser

,

/self-service/registration?flow=...

- Hydra:

/oauth2/auth

,

/oauth2/token

- Automatic Login: Achieved via Kratos registration hooks that create a session post-signup. --- Note: The exact implementation details (e.g., how the SPA handles cookies, CSRF, and state management) depend on your frontend framework and deployment setup. The above flow is based on the documented integration patterns and may require additional configuration for production environments[Self-service flows](https://www.ory.sh/docs/kratos/self-service), [Custom login and consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#flow-steps).

When Hydra receives a request to the

/oauth2/auth

endpoint, it needs to determine if the end user is already authenticated. Hydra does not manage user sessions itself; instead, it delegates authentication to an external identity provider (like Ory Kratos). How does Hydra know which user is authenticated? - Hydra checks for a session cookie that was set by the identity provider (Kratos) after a successful login. - If the session cookie is present and valid, Hydra can identify the user associated with that session. - If there is no valid session cookie, or if the session is expired or invalid, Hydra redirects the browser to the login endpoint you configured (typically a Kratos login UI), passing along a

login_challenge

parameter. - After the user authenticates with Kratos, Kratos sets the session cookie, and the browser is redirected back to Hydra, which can now recognize the authenticated user via the session cookie. This process is described in the Ory documentation: > Ory OAuth2 and OpenID Connect checks if a session cookie is set containing information about a previously successful login. Additionally, OpenID Connect parameters

id_token_hint

,

prompt

, and

max_age

are evaluated and processed. Depending on their values and the login state, the user might need to re-authenticate or the flow will fail. > To authenticate the user (this happens regardless of whether a session exists for the user or not), Ory OAuth2 and OpenID Connect redirects the browser to the "login endpoint" established in your config. [User login and consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow) In summary: Hydra knows which user is authenticated by checking for a valid session cookie set by Kratos. If the cookie is present and valid, Hydra can identify the user; otherwise, it triggers the login flow.

Certainly! Here’s a step-by-step outline of the user logout flow when using Ory Kratos (for identity/session management) and Ory Hydra (for OAuth2/OIDC), including the relevant API calls and logic, based strictly on the provided knowledge sources. --- ## 1. Initiate Logout in the SPA - The SPA triggers a logout action (e.g., user clicks "Logout"). --- ## 2. Invalidate the Kratos Session For browser-based applications: - The SPA initiates the logout flow by calling Kratos to get a logout URL:

GET /self-service/logout/browser

Kratos responds with a

logout_url

and a

logout_token

. - The SPA then completes the logout by calling:

GET /self-service/logout?token=<logout_token>

This invalidates the user's session and removes the session cookie from the browser. After logout, the user is redirected to the specified return URL or the default post-logout URL configured in Kratos[Logout flow - Kratos](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#logout-flow), [Logout - Kratos](https://www.ory.sh/docs/kratos/self-service/flows/user-logout). --- ## 3. Logout from Hydra (OIDC/OAuth2 Session) - To log the user out from Hydra (and trigger OIDC front- or back-channel logout for connected clients), the SPA redirects the user to Hydra’s logout endpoint:

GET /oauth2/sessions/logout

This endpoint initiates and completes user logout at the Ory OAuth2 & OpenID provider and triggers OIDC front-/back-channel logout as needed[Hydra API Reference - revokeOidcSession](https://www.ory.sh/docs/hydra/reference/api). - Optionally, you can include parameters such as

id_token_hint

,

post_logout_redirect_uri

, and

state

to control the post-logout redirect and maintain state:

GET /oauth2/sessions/logout?id_token_hint=<id_token>&post_logout_redirect_uri=<url>&state=<random>

Hydra will redirect the user to the specified URI after logout[OIDC Logout - Redirect after logout](https://www.ory.sh/docs/oauth2-oidc/oidc-logout#redirect-after-logout). --- ## 4. (Optional) Custom Logout UI/Endpoint - If you have a custom logout UI or endpoint, you may need to handle the logout challenge from Hydra: 1. Fetch the logout request:

GET /admin/oauth2/auth/requests/logout?logout_challenge=<challenge>

2. Accept or reject the logout request using the appropriate API call, then redirect the user as instructed[Implementing the OIDC logout endpoint & UI](https://www.ory.sh/docs/hydra/guides/logout). --- ## Summary Table | Step | Service | API Call | Purpose | |------|---------|----------|---------| | 1 | Kratos |

/self-service/logout/browser

| Initialize logout, get logout URL/token | | 2 | Kratos |

/self-service/logout?token=...

| Invalidate session, remove cookie | | 3 | Hydra |

/oauth2/sessions/logout

| OIDC/OAuth2 logout, trigger front/back-channel logout | | 4 | Hydra (optional) |

/admin/oauth2/auth/requests/logout

| Custom logout UI/logic | --- Note: - The order of logout (Kratos first, then Hydra) ensures both the identity session and OAuth2/OIDC sessions are invalidated. - For SPAs, these calls are typically triggered via browser redirects or AJAX, depending on your architecture. If you need code examples for these steps, let me know!

Certainly! Here is the step-by-step logout flow for a user in an Ory Kratos + Ory Hydra setup, including the API requests and example response payloads, strictly based on the provided knowledge sources. --- ## 1. Initiate Logout with Ory Kratos Step 1: Get the Logout URL and Token Request:

http GET https://<kratos-project>.<http://projects.oryapis.com/self-service/logout/browser|projects.oryapis.com/self-service/logout/browser> Cookie: <session_cookie> Accept: application/json

Response:

json {   "logout_url": "https://<kratos-project>.<http://projects.oryapis.com/self-service/logout?token=J6yIQf7ABx1BBiPOj036dJKSQmKwGnX6|projects.oryapis.com/self-service/logout?token=J6yIQf7ABx1BBiPOj036dJKSQmKwGnX6>",   "logout_token": "J6yIQf7ABx1BBiPOj036dJKSQmKwGnX6" }

[Source: Kratos Custom UI Integration - Logout Flow](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#logout-flow) --- Step 2: Complete the Logout Request:

http GET https://<kratos-project>.<http://projects.oryapis.com/self-service/logout?token=J6yIQf7ABx1BBiPOj036dJKSQmKwGnX6|projects.oryapis.com/self-service/logout?token=J6yIQf7ABx1BBiPOj036dJKSQmKwGnX6> Cookie: <session_cookie> Accept: application/json

Response: - On success, the session is invalidated, the session cookie is removed, and the user is redirected to the post-logout URL (no JSON body is returned; it's a redirect). [Source: Kratos Custom UI Integration - Logout Flow](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#logout-flow) --- ## 2. Logout from Ory Hydra (OIDC/OAuth2 Session) Step 3: Initiate OIDC Logout Request:

http GET https://<hydra-project>.<http://projects.oryapis.com/oauth2/sessions/logout|projects.oryapis.com/oauth2/sessions/logout>

Response: - The response is a

302 Found

redirect. Hydra will handle OIDC front- and back-channel logout and redirect the user as configured. No JSON body is returned. [Source: Hydra API Reference - revokeOidcSession](https://www.ory.sh/docs/hydra/reference/api) --- ## 3. (Optional) Custom Logout UI/Endpoint with Hydra If you implement a custom logout UI, you may need to handle the logout challenge: a. Fetch the Logout Request Request:

http GET /admin/oauth2/auth/requests/logout?logout_challenge=<challenge>

Response: - Returns details about the logout request (payload not fully specified in the sources). b. Accept the Logout Request Request:

http PUT /admin/oauth2/auth/requests/logout/accept?logout_challenge=<challenge>

Response:

json {   "redirect_to": "<https://client-app.example.com/post-logout>" }

[Source: Implementing the OIDC logout endpoint & UI](https://www.ory.sh/docs/hydra/guides/logout) --- Summary Table | Step | API Call | Example Response | |------|----------|------------------| | 1 |

GET /self-service/logout/browser

|

{ "logout_url": "...", "logout_token": "..." }

| | 2 |

GET /self-service/logout?token=...

| Redirect (no JSON) | | 3 |

GET /oauth2/sessions/logout

| Redirect (no JSON) | | 4a (optional) |

GET /admin/oauth2/auth/requests/logout

| Logout request details | | 4b (optional) |

PUT /admin/oauth2/auth/requests/logout/accept

|

{ "redirect_to": "..." }

| --- If you need more detailed payloads for the optional custom UI steps, please specify, as the knowledge sources do not provide full example bodies for those endpoints.

The

/oauth2/sessions/logout

endpoint of Ory Hydra (OIDC/OAuth2 provider) is typically invoked by the **client application**—in this case, your Single Page Application (SPA)—when the user initiates a logout action. The SPA triggers this endpoint (usually via a browser redirect) to ensure that the user's OAuth2/OIDC session is terminated and that any configured OpenID Connect front-channel or back-channel logout flows are executed. This is confirmed in the Ory documentation, which describes that the endpoint is used to initiate and complete user logout at the Ory OAuth2 & OpenID provider, and is intended to be called as part of the logout flow from the client side (such as a browser or SPA) [Hydra API Reference - revokeOidcSession](https://www.ory.sh/docs/hydra/reference/api). If you have a custom logout UI, you may also invoke this endpoint as part of your server-side logic, but in standard SPA scenarios, it is the SPA (client) that calls this endpoint to log the user out from Hydra.

To specify token expiry times for each OAuth2 client when registering in Ory Hydra, you can include lifespan fields in the client registration request body. These fields allow you to set the expiration time for different token types (access token, ID token, refresh token, etc.) per grant type, using a string duration format (e.g.,

"1h"

,

"30m"

,

"24h"

). Here’s how you can do it: ### Example: Registering a Client with Custom Token Lifespans Request:

json POST /admin/clients Content-Type: application/json  {   "client_id": "my-client",   "client_secret": "my-secret",   "grant_types": ["authorization_code", "refresh_token"],   "redirect_uris": ["<https://myapp/callback>"],   "authorization_code_grant_access_token_lifespan": "1h",   "authorization_code_grant_id_token_lifespan": "12h",   "authorization_code_grant_refresh_token_lifespan": "24h",   "refresh_token_grant_access_token_lifespan": "1h",   "refresh_token_grant_id_token_lifespan": "12h",   "refresh_token_grant_refresh_token_lifespan": "24h" }

Supported lifespan fields include: -

authorization_code_grant_access_token_lifespan

-

authorization_code_grant_id_token_lifespan

-

authorization_code_grant_refresh_token_lifespan

-

refresh_token_grant_access_token_lifespan

-

refresh_token_grant_id_token_lifespan

-

refresh_token_grant_refresh_token_lifespan

-

implicit_grant_access_token_lifespan

-

implicit_grant_id_token_lifespan

-

client_credentials_grant_access_token_lifespan

-

jwt_bearer_grant_access_token_lifespan

-

device_authorization_grant_access_token_lifespan

-

device_authorization_grant_id_token_lifespan

-

device_authorization_grant_refresh_token_lifespan

Each field accepts a string duration (e.g.,

"1h"

,

"30m"

,

"24h"

), and the pattern is validated as described in the API reference[^1]. Note: If you do not specify these fields, Hydra will use the global default values. [^1]: [Hydra API Reference – createOAuth2Client](https://www.ory.sh/docs/hydra/reference/api) --- In summary: Specify the desired token lifespan fields in the JSON body when registering the client via the

/admin/clients

endpoint. The values should be duration strings such as

"1h"

,

"30m"

, etc., as supported by the API.