Make Forgerock cookie Session or Persistent cookie depending on user input

Integrations
, , ,
#1

During Login, we ask our customer if they want to “Keep signed in” with a checkbox. This means that if they close their web browser and re-open it again later, they will still remain logged into Forgerock.

This is usually handled by a “Persistent” cookie with an expiry date, as opposed to a “Session” cookie, which has no expiry date set.

We’re using the Forgerock SDK for integration, but when we login, it seems we will get two cookies, as Session cookie and Persistent cookie.

This isn’t ideal, as when we close the browser, the Session cookie will disappear and we’re no longer logged in.

Has anyone else managed to configure their journey to handle a dynamic Session vs Persistent cookie situation more easily?

#2

Hello Peter,

Correct, a persistent cookie may act as a means (requirement) of authentication to which the session cookie is an outcome.
We should not offer no expiry sessions. In turn, you may use the “Persistent Cookie Decision Node” within your Authentication Tree. Similarly, there is the “Set Persistent Cookie Node”.
Please do see Persistent Cookie Decision node :: AM 7.4.0

Cheers

#3

Well the SSO cookie is a Session cookie (with no expiry) but in reality, it will still expire server-side in forgerock, so it can’t be used after the internal expiry date.

So how do other websites implement this type of functionality?

Should the default setting for the SSO cookie be Session or Persistent?

Also, it seems like the new Persistent cookie created by “Persistent Cookie Decision Node” isn’t a true SSO cookie… and we are expected to use the Persistent cookie to request a new SSO cookie… so we can continue to call the APIs.

I’m missing something here… :slight_smile:

#4

Yes… you are missing the point that the cookie created by the Persistent cookie decision node is the “next” persistent cookie. It is not the cookie containing the session tokenid.

#5

Ok, so its more of a secondary cookie then?

And only useful for exchanging for a new (Session) SSO cookie then?

Ok…

So lets say I’ve logged in, I’ve got my SSO cookie and now my 2nd persistent cookie.

I then close my browser… the SSO (Session) cookie disappears and I’m left with the persistent cookie.

If then I want to hit a “Journey” I need that journey to contain a “Persistent Cookie Decision node” which will 1. Detect the Persistent cookie and 2. Reissue the SSO (Session) cookie. Great!

But instead… assuming I now only have the Persistent cookie again… if I then want to call one of the APIs, such as Logout, then I can’t use the Persistent Cookie directly right…? I must call a journey to exchange it for an SSO…

This really weird odd behaviour or is there a better way to handle this. Should I be looking at OAuth tokens instead…?

#6

Secondary?? It is the response to the challenge “do you have a persistent cookie?”

Your second use case will have the same challenge… That is,
With sso, you will need a valid ssotokenid to access the resource.
With OAuth2, you will need a valid token to access the resource.

In both cases, should the token be invalid, an exchange will need to occur. Even if you are using refresh tokens of course, in order to elongate the validity period.