Does Kratos support or plan to support OpenID Conn...
# talk-kratos
c
Does Kratos support or plan to support OpenID Connect RP initiated logout? It would be really handy for mobile use cases. See the spec here: https://openid.net/specs/openid-connect-rpinitiated-1_0.html
i
Actually, OIDC flows are managed by hydra, incl the flow you're asking for. You can find more information here https://www.ory.sh/docs/hydra/debug/logout. Hopefully that helps
Kratos will never support it as it is just an identity management system. Can't speak for Ory however 😉
c
Does the hydra-kratos integration support clearing the Kratos session then when this endpoint is called? I am very confused about the role of Hydra in session management. My understanding was this was all in Kratos (cookies, etc)
i
Good question. I'm using a custom integration between the two. So can't tell about the one provided by Ory. I would assume this is the case. But since you asked your initial question, I may be wrong
c
Interesting! Do you have any advice or examples where you needed a custom integration? We're just starting with Ory, looking to build a fully-featured IdP but the component integrations seem to be missing.
(Missing from the OSS offerings and guides)
i
Actually, until about a year or so, there was no official (delovered from Ory) integration code for hydra and kratos. There were however (and actually still are) some example applications from Ory covering that. In addition, there is an API documentation and some sort of guides covering that as well.
However, I'm not sure whether that option is available with the cloud offering from Ory. I'm using a self hosted setup
c
We are using self-hosted as well. The new integration came mid this year if I recall and that's around when we started. So we haven't looked beyond their integration. My concern is mainly around groups/roles and sessions and where that lives within the Ory tool ecosystem. Also where the mapping of "scope -> user" is stored.
I wouldn't say our questions are necessarily around the integrations, because as you say there are documented examples, but more around how to do simple things that an IdP should be able to do ...
i
Groups/roles is Keto Sessions is Kratos OIDC incl scopes is hydra. The mapping between the scope and the user happens in the glue code between kratos and hydra for the id token. Everything beyond the scopes defined by oidc is the responsibility of your services, respectively in something which gives access based on the scopes granted to the client and referenced in the access token.
... how to do simple things an idp should be able to do
The great thing about ory products is that they focus on particular concerns related to "things" people tend to see (for historical reasons) in an IdP. That approach gives you freedom and flexibility no idp out there can offer. But you lose "expected convenience". The available services provide those "things", but in a different way and they force you to think about what you need and how you need those.
c
Right so it's the glue code that really ties it all together (and that bit is missing for us currently). What trips us up there is that the user information is stored in Kratos, but is needed by both Hydra and Keto to do things like role determination or scope mapping.
i
Hydra just stores/manages, what the glue code sets. That's all. Hydra by itself doesn't care about the user. The only thing it asks the glue code: give me the stuff I have to take care about. So you can use hydra with any identity management system out there. It even does not do scope mapping, this is the glue code.
... do things like role determination or scope mapping.
This is out of scope for OAuth2 and OIDC but this is what all idp solutions out there try to sell you. Roles have nothing in common with scopes. Roles are about user authorization. Scopes are about client authorization. If you try abusing scopes for that - wish you fun 😉