Implicit Grant Token life with SSO vs GC login

We have built a script that is triggered on call delivery to run a web browser with the URL of the web-page running the java-script SDK. The the web-page uses implicit grant to authenticate the user & then performs a getConversations request.

The customer org is configured with SSO & the client is using the Genesys Cloud Desktop application.

The behavior we are seeing is that the agent is prompted to login on 1st screen-pop, which they do using the SSO option.

  • If they receive calls frequently, then the screen-pop works as expected/normally
  • If they don't receive another call for an hour, the screen-pops requests the user to login again

I have tried to replicate this behavior in our own org using the Genesys Cloud Desktop application as well, but have not been able to reproduce it

  • It works all the time regardless of length of time between calls.
  • The difference is that my org does not have SSO enabled, so I am using the Genesys Cloud login.

My suspicion is the the Genesys Cloudtoken has a life expectancy of 24-hours (From memory?) while the AD SSO token has a 1-hour life expectancy, as defined in the AD.

What I'm looking for is confirmation of this theory?
- Or pointers to another theory that I may not have considered

I found this article:

However the behavior described in that suggested the user was being prompted for SSO login each time, where I'm only getting it if there is a long interval between requests, so was different to my experience.

Hi Lloyd,

I've asked some colleagues of mine who are more knowledgable in this topic and the response I've gotten is:

There are two different mechanisms in play here.

  1. The login.{env} domain maintains a browser session cookie that has a short lifespan. If the cookie is present and still valid then a user is considered authenticated and a token can be created without prompting the user to authenticate. The lifespan of the session cookie is not configurable.
  2. An access token is created after a user has proven their identity. The access token expiration is configurable on the oauth client where it has a maximum age of 48 hours.

I hope this answers everything.

Thanks Ronan,

That explanation makes sense, however doesn't seem to correlate with the experience/behavior we are having.

We have recently built a brand new Azure AD, so I have enabled SSO with our org so I can replicate the customer issue.

After extensive testing we've found that the login prompt is presented on the screenpop (with Implicit grant) after 20 minutes.

  • Screenpops within 20min of each other do not require credentials
  • Screenpops after 20min require credentials

So the 20 minutes would make complete sense when matched to your answer 1. about the session cookie having a short lifespan.

EXCEPT that this does not occur when Genesys Login credentials are used

We can see this behavior in both our & the customers organisation, so it is not unique to just one AD or Genesys Cloud org.

  • We are using the Genesys Desktop client, not a browser
  • During testing the Genesys Desktop Client was started and remained open
  • All AD token timers/etc. are at their Microsoft defaults in the new Azure AD as it’s a brand new AD

So from our testing, it appears that the session cookie in the Desktop client has a different lifespan based on whether a Genesys Login, or a SSO AD login was used to authenticate the user.

  • Is that behavior being different using Geneys login vs SSO expected?

  • Can you give us any guidance on any Microsoft token/timer values that are influencing this behavior?

Thanks again
Lloyd

Ronan's answer is correct in the context of using Genesys Cloud authentication, but does not apply to SSO. When using SSO, Genesys Cloud does not use the aforementioned session cookie. In the context of SSO, the length a user may go between providing credentials to the 3rd party authentication service is defined by that 3rd party service. In your context, the agent is being challenged for credentials after 20 minutes because that is what Azure AD is deciding to do.

Additionally, as a best practice, your application should remember the auth token between sessions to reduce the number of times the user needs to be redirected to the login service to get a new token. This can be accomplished with a setting in the SDK or via any means your app prefers. https://developer.mypurecloud.com/api/rest/client-libraries/javascript/index.html#access_token_persistence

Thanks Tim,

I've implemented this today in Dev & it appears to work, putting it in for the customer site tonight.

One of the questions I can foresee will be a question on the browser cookie session life.

What would be the expected session life when extended? (Essentially how long between screen-pops that implement the implicit grant before being prompted with login again)

Lloyd

Remembered sessions are valid for 3 months. Keep in mind that there are circumstances that will invalidate the remembered session, like logging out or changing the user's password.

Perfect - Thanks for clarifying that Tim.

Your recommendation to set the token persistence is working for the customer, so many thanks for your time & help on this Tim & Ronan.

Lloyd

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.