Yes, thanks for pointing to this issue, I will watch it. And now I understand where session_id and login_challenge_id are coming from. Yes, basically, I was thinking about the use case like this:
- I develop an API, it does store some personalized data based on the identity of the calling resource owner
- I also develop an app that uses this API and allows the user to log in
- I use an external identity provider, e.g. something like Azure AD Connect (via OIDC)
- I also understand that OAuth2 is not a good way to implement any kind of authentication. I also understand that from the authentication point of view, the only thing I can rely on, is the fixed subject identifier+authentication “issuer”. This is the “primary key” for the user “profile” in my own system. I understand the difference between my user and Azure AD user.
- Considering the previous point, just the subject value may not be enough in case of multiple IdPs used. I want to make sure that the users from different IdPs never clash. Currently I am thinking about generating my subject value by prefixing it with an ID/URL of the ID_TOKEN issuer.
So, technically, the challenge here is mostly about initializing this profile with email/first/last name/etc - the information from the ID_TOKEN I get from Azure AD Connect. So the app could use this information to initialize its own profile.
In the systems like Keycloak, where IdP and OAuth2 server are both implemented by one product this sounds more obvious, I think. But I really like the idea of the system where the API Gateway (like Ambassador) essentially “terminates” OAuth2 bearer token and the API (micro)services only get some relevant claims in form of HTTP headers. This makes even OAuth2 server replaceable - to certain extent, of course. Then, I like Hydra because it is a small and fast OAuth2 server that may be just enough for some use cases, like client credentials grant, for example (service-to-service, B2B-type integration). And I like the idea of having my login provider relying on real OIDC ones. This way I have completely replaceable/pluggable IdP implementation, somewhat replaceable OAuth2 server and totally authorization-agnostic backend.
I was thinking about how to pass the ID_TOKEN from the login provider to the consent provider and saw these options:
- shared in-memory DB or cache, I need very small amount of data for a very limited time
- session cookie (would have to still mix in the login challenge)
- an argument/query parameters added to the final redirect from the login provider - but that would require support from Hydra
Only the first option allows to avoid extra trips for the ID_TOKEN but it requires statefulness from my, otherwise stateless, login/consent providers.