Session expiration

Hi

I’m working on implementing Hydra in order to have a centralized identity provider / user management app which will be used by multiple of our products (which are setup as separate oauth clients) to authenticate users. The user should be able to login once centrally with open id and seamlessly be able to authenticate with any product without needing to provide credentials again.

One of the requirements we have for compliance reasons is session expiration. Specifically we wish to start a countdown when someone logs in which will eventually mean the session is expired, but we want the clock to be reset if the user is active on one of the products so they don’t get logged out if they are active.

I know hydra has “remember” and “remember_for” fields that can be set when accepting a login challenge which define what the expiration date is set to on the hydra session cookie. However, once set I don’t believe this can then be extended (docs say that it has no effect if “skip” is set to true which would be the case where a session already exists.

So I don’t think setting this will work because if the user is active on one product, they would have to provide credentials again to access a different product if it’s been a while since they last provided credentials.

Is there a recommended way to handle this?

To add a bit of context about the implementation I have so far.

  • I’m using backchannel logout so that if a logout is done centrally it kills the session the user agent has with all products.
  • Also I know this kind of goes against what the docs say you should do but my login challenger endpoint does itself store some state. As part of login challenge (after they supply correct creds, but before I call hydra to accept the challenge) I make the user choose which organization they want to scope their session to if they are a member of multiple, this goes into the id token. I store this preference in redis with a key containing the “sid” of the login challenge so future logins challenges where the user already is logged into hydra can share that data without the user being asked for it again. But as I’m using hydra’s session id to store against I don’t foresee any major issues with this (I’m not using a session cookie of my own). In fact one solution to the above problem could be to piggy back off this and have products call out to a url within the login provider endpoint to reset the clock for a given hydra sid, and then check this within the login challenge. But would be interested to hear thoughts on this.

Thanks in advance

Matt

One of the requirements we have for compliance reasons is session expiration. Specifically we wish to start a countdown when someone logs in which will eventually mean the session is expired, but we want the clock to be reset if the user is active on one of the products so they don’t get logged out if they are active.

OpenID Connect is a third-party “SSO” system, not a first party. Its primary use case is “log in with google/github/facebook/twitter”. For example, create an account at GitHub. Then use that account to sign into CircleCI or TravisCI. Log out of GitHub. You will notice that you’re still signed in in CircleCI. That’s because those are separate systems on separate domains with separate companies and separate flows.

Having said that, you can do global sign out OpenID Connect Front/Backchannel logout (as you already mentioned). It definitely adds complexity but it’s one way of solving “global sign out” in a first-party scenario.

Regarding activity, that’s a tough question, but a good one. Maybe you could work with some of the OpenID Connect Implicit flows (“hidden iframe refresh”) to refresh the session, as long as the user is on the website and/or active. That way, you would continuously hit your consent app and could execute some logic based on the active state. In that case, keeping state is fine.

Also I know this kind of goes against what the docs say you should do but my login challenger endpoint does itself store some state. As part of login challenge (after they supply correct creds, but before I call hydra to accept the challenge) I make the user choose which organization they want to scope their session to if they are a member of multiple, this goes into the id token. I store this preference in redis with a key containing the “sid” of the login challenge so future logins challenges where the user already is logged into hydra can share that data without the user being asked for it again.

That is absolutely legitimate!

Personally, I’d recommend something like github.com/ory/kratos for what you’re up to. However, that product is not yet in a releaseable state. We’re planning to release the first version by the end of 2019 or in Q1 2020. We have not really thought about “activity” yet but it’s a good use case and I personally have seen that a lot in banking software.

Hope this helps.

Thanks for the detailed reply arekkas.

I will look into the activity thing.

We are quite far on with the project now, planning to release early Q1 but I think for our use case, implementing the user management our system was a plus. We have to migrate users from a few different products, all with their own quirks that we need to try our best to still support with the centralised system.