Posting this issue following discussion with @hackerman in the chat.
Our management wants a single IdP and wants some form of user profile page, i.e. a page where users can update their data. These users would go to login.whatever.com, sign-in and find themselves in their account page where they can do two things:
- update the mutable profile data
- review active consents with the ability to revoke
I understand Hydra is not an SSO solution but I still want to integrate that IdP with Hydra so that every third party client does OAuth2/OIDC.
How can we achieve this? Hydra’s own authentication session management (i.e. the remember user feature) cannot be used if you want to be able to sign-in without performing an OAuth2/OIDC flow.
I suggested the following but @hackerman came with valid counter-arguments.
Hydra docs say that we should not do any session management on the login endpoint. Is there a reason why we shouldn’t do so? Is it a security risk? Is it a spec compliance problem? It is not clear from the docs whether it’s because we don’t need to (thanks to Hydra’s session management) or whether we MUST NOT do it at all because our house will burn.
I am trying to figure out if it would be ok if we always tell Hydra to never remember auth sessions and do session management on our side instead.
you MUST NOT do it, if you don’t synchornize the users you can get impersonation
I don’t really get how I can get impersonation here. I remember a user that has previously logged-in just like Hydra does with its own cookie. When performing the OAuth2 flow, hydra redirects the user to the login endpoint. Why can I not say the user is already logged-in, so let’s just get the login request from the challenge, then just tell Hydra we accept the login request and redirect back to hydra (just like Hydra does when it tells us to skip the login screen)?
because hydra may remember it’s own user id
so hydra says: “yo it’s user X”, your session says: “you it’s user Y”, which user is it?
if Hydra tells me who the user is then I obviously can’t use that
that’s why I don’t want Hydra to remember sessions
I understand this risk and I guard against that specific case, i.e. in my login endpoint if the challenge tells me that Hydra tells me who the user is, I invalidate the session.
I also verified that Hydra checks for this specific case
@hackerman also highlighted the fact that foregoing Hydra’s OIDC session management would put the burden on the login endpoint to do this. He suggested some alternative solutions:
- using something like bitly/oauth2_proxy
- using Hydra’s session management and checking against the local session
- use a normal OAuth2 flow with the account/profile page
All come with their own set of problems/limitations 
I like the second approach. Let Hydra still do its OIDC session management and only use the local session if there is no incoming challenge. What bothers me is the fact that if Hydra has a valid session then you don’t allow the user to choose a different identity. That’s a UX problem or there is a burden on the third-party OAuth2 clients to play with the prompt parameter.
Are there any alternative approaches that would simplify the situation?