how do hydra sessions and kratos sessions relate to each other? if someone authenticates via hydra using kratos for login, kratos issues a session id, but is there a different session created for oauth? if so, how are / are they linked?

Yes, there are basically 3 session layers if you use auth via OAuth2 • Application Session Layer: This layer is the session inside your application managed by Ory Identities/Kratos. Though your application uses Ory Identities/Kratos to authenticate users, your application also tracks that the user has logged in to your application; in a regular web application, for example, you achieve this by storing this information inside a cookie. • OAuth2 Session Layer: Ory OAuth2/Hydra also maintains a session on the Authorization Server for the user and stores their user information inside a cookie. This layer is used so that the next time a user is redirected to Ory OAuth2/Hydra for login the user’s information will be remembered. This session layer makes the SSO experience possible for inbound SSO implementations. • Identity Provider Session Layer: When users attempt to sign in using an identity provider such as Facebook or Google, and they already have a valid sign-in (with whichever provider they choose) they will not be prompted again to sign in though they may be asked to give permission to share their information with Ory OAuth2 and, in turn, your application. See this blogpost also https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/

Great thanks @magnificent-energy-493! I already reviewed that article thanks - we have a number of different usages that cover most of those use cases, and we need to work out the implications. Part of that is figuring out whether hydra and kratos sessions (are intended to) link up at all - i know kratos can provide identity management for hydra oauth/oidc, so what I'm trying to understand fully is whether there is any link held between the kratos session created and the oath session resulting from the login? Or is it the case that they are entirely separate and know absolutely nothing about each other?

The sessions are linked to the same identity I think by identifier

🤔 could you give me a pointer to the details on that? have been poking through the hydra code base but haven't turned it up yet, it would really help if I could see where and how that link is done. all help gratefully appreciated 🙂

Somewhere in the glue code between kratos and hydra, you'll find something like

// login successful
alr, err := h.hc.Admin.AcceptLoginRequest(
  admin.NewAcceptLoginRequestParams().
		WithLoginChallenge(loginChallenge).
		WithBody(&models.AcceptLoginRequest{
			Acr:         "0",
			Context:     identityInfo,
			RememberFor: 3600,
			Subject:     &identityInfo.Id,
		}).
	WithContext(ctx))

The sole linking is done in the line

Subject:     &identityInfo.Id

line. Where

identityInfo.Id

is the identifier of the user in kratos and

identityInfo

being of type

Identity

from kratos client package. The call to

NewAcceptLoginChallenge

is a call to hydra API to proceed with the flow upon successful authentication with kratos and the reception of the corresponding (mentioned above) information. Please note: I've explicitly written "something like", as the above snippet is from our own glue code. Hopefully that helps.

Yes that does help thank you @icy-manchester-83109! I can stop looking for the link now 😄 As a follow on question, when you use hydra for oauth/oidc and kratos as identity manager, does hydra logout only affect the hydra session then? As in: the associated kratos session would live on until it expires unless the client app makes an explicit call to logout the kratos session to the kratos api as well?

TL;TR yes and yes. Longer Explanation

when you use hydra for oauth/oidc and kratos as identity manager, does hydra logout only affect the hydra session then?

Hydra is a token manager. As simple as that. It doesn't know anything about identities and does nether manage logins or logouts of real users. The only thing it knows - there is that client, which asked to issue that or that set of tokens. That's all. The "session" created by hydra is just an object, which allows hydra identifying the client - token pair, which is valid. That's all. Yes, there is an extension for oidcs - frontend and backend logout, also supported by hydra. But these two are mean to inform the clients, that the tokes, they're using should be dropped and not used anymore. Here you could implement your own logic to invalidate the kratos session by starting the logout flow. Given the above explanation, the answer to your second question

As in: the associated kratos session would live on until it expires unless the client app makes an explicit call to logout the kratos session to the kratos api as well?

is yes. One side note: Depending on your OIDC/OAuth2 usage pattern, you might even not really be able to "logout" the user. E.g. if you use tokens in JWT format, the resource server will never make a call to the introspection endpoint upon reception of such token, and for that reason not even know, that the token is not valid any more and should not be trusted. Another side note: There is actually no such thing as a session, or login, respectively logout with OAuth2/OIDC. The login is just part of the flow to have the token issued. Nothing more. As long as the token (including the refresh token) is valid, the bearer of that token can do whatever the token allows to do, hence the "bearer token". For that reason it is a fallacy of thinking there is a "login session" with an OIDC/OAuth2 provider if we focus on OIDC/OAuth2 as protocols. Login, logout and session management of the real "session" associated with the subject is entirely out of scope for OIDC/OAuth2 protocols. The OIDC/OAuth2 provider can have, and typically has its own session management (Hydra is a positive exception here as it outsources that to the real identity management system giving you the freedom to use whatever you want). But the client will typically have its own session management as well based on the information received from the id token and can for sure logout the user (drop the access token, and hopefully invalidating it before dropping by making a call to the revocation endpoint) without affecting the session managed of the entity, which issued the token.

that is a brilliant explanation! thanks @icy-manchester-83109 🙂

No, no. consent is part of OAuth2/OIDC. This is related to the dialog with the "permissions" you give to the client. If we stay in the nomenclature of OAuth2 and OIDC, there are • scopes - these are the "permissions", the client would like to have to do something. E.g. OIDC defines a standard set of scopes, like

email

, which the client can set, if it want to have the email address of the user for whatever reasons. That value will then be set in the id token, but also be then available as result to the request to the user info endpoint (implemented by a resource server, which in that case is part of the auth provider). Here, the OIDC provider will receive the token, see "aha, email scope is set, so I'm allowed to provide that value" and add the corresponding claim to the respone. • resource owner consent - when the client starts the flow, e.g. the authorization code flow, it sets also the scopes, it needs to the request to the auth rovider. Upon successful authentication of the resource owner, the auth provider will render a "consent dialog", which shows the resource owner, which client application wants accessing which data owned by the resource owner. Here, the resource owner can then say "I allow this, that and that, but not that". When the resource owner then clicks the submit button, the "consent" is sent to the auth provider. With that "consent" that auth provider creates a set of tokens, which reference that consent. When the flow completes, the client will receive that set of tokens and also the information which from the requested scopes were granted (so which consent the resource owner has given). E.g. if the scope "offline_access" has been granted by the resource owner, that set will contain the refresh token. Without it, there will be no refresh token. Now, the client, if the given consent is enough for doing its business, can communicate to the resource server by making use of the access token. The resource server will check, whether the request to the given resource has been granted by the resource owner. E.g. If the request is made to an imaginary

/photos

endpoint, it will check, whether the imaginary scope

photos

has been granted. If yes, it will answer with whatever it answers and if there was no consent for that scope, it will deny the request. Basically the same way, the auth server replies to the request to the user info endpoint as sketched above. So far the theory.

ok perfect thank you for taking the time 🙂 you have been of great help 🙂

You're very welcome!

🙂 noted! unfortunately my german isn't up to much!

Very cool Dimitrij! I had no idea, I will see to join sometime!