Logout/timeout issues with G Suite SSO

[aripringle]

We recently set up our JSS instance to use G Suite for Single Sign-On, following these instructions: https://www.jamf.com/jamf-nation/articles/440/configuring-single-sign-on-with-g-suite-google-apps

Everything is working well, except after a certain amount of time, the user starts getting SSO errors like this when attempting to log into JSS: "An error occurred while processing your Single Sign-On request. Contact your administrator for assistance."

When this happens, it appears that the only way to fix it is to log out of Google and back in, which is not the ideal user experience. It also prevents us from being able to use authentication in the Self Service app, since there's not an easy way to force a Google logout inside of it.

I haven't tested the exact timeframe, but I believe this occurs after the SAML Token Expiration (which is defined in the JSS as 480 minutes). I can increase this, but I'm not sure what the ideal setting is, or if increasing it would just postpone this issue.

I'm curious if anyone is successfully using G Suite SSO and not experiencing these timeout issues?

I've seen some similar discussions related to this (like https://stackoverflow.com/questions/40939839/google-apps-sso-as-idp-into-spring-saml2-authentication-token-timeout), but haven't found any real solutions.

[aripringle]

Just wanted to share, after my initial post, we increased the SAML Token Expiration in Jamf Pro to 108,000 minutes (75 days), which seems to have resolved it (at least mostly).

We still seem to have the occasional user that tries to login to do User-Initiated Enrollment and ends up needing to log out of Google and back in (even if this is the first time they're logging into our Jamf instance, so I'm not 100% sure that it's related). But, I haven't seen it happen on my own account since making the change.

[thomas-cedar]

We ran into this issue at our company as well. We ended up disabling SSO, because it was more trouble than it was worth.

[crystallized]

I'm having this issue now as well, have found this thread and https://productforums.google.com/forum/#!topic/apps/Chg9VfFJZFM mentioning it but no solutions either. Extending token expiration to almost three months seems unreasonable. Has anyone found anything? I might put in a support ticket.

[jamfusername]

Confirmed issue with G Suite and Jamf. This is the only SaaS SSO setup I have with G Suite that has this issue.

Also, confirmed that extending the token timeout does have a direct impact on the symptoms I was seeing.

[RolfZ]

We are also experiencing this Issue, I have opened a support case regarding this issue.
Is any one else seeing this error message in the JSS Logs when SSO fails:

2020-08-24 11:52:20,603 [WARN ] [ina-exec-37] [TokenAuthenticationFilter] - Illegal base64url character: '&' io.jsonwebtoken.io.DecodingException: Illegal base64url character: '&' at io.jsonwebtoken.io.Base64.ctoi(Base64.java:206) ....

[boatymcboatface]

Confirmed, increasing the SAML Token Expiration in Jamf Pro to 108,000 minutes resolved this issue for us too (at least for 75 days). A permanent fix from Jamf someday would be most helpful. 

[bradtchapman]

We're seeing this issue with Ping Identity.  First sign-in to Jamf after several hours results in the pages stuck in the "spinning ring" phase, with a gray Jamf "sad face" in the background.  Reloading the page takes me back to the Duo 2FA prompt.  After passing the second time, Jamf behaves normally for most of the day.

Our timeout is 480 minutes, the default.  The suggested workaround makes sense; however, it seems like Jamf should invalidate some part of the token so it is "fresh" every time the person signs in.

[user-voiZiJyJvM]

I know this is now a pretty old topic but in case it helps anyone reading: I disabled "Token Expiration Time Override" on the SSO settings page and so far this has fixed the issue! 

[RolfZ]

Hey thank you for this tip. Wile yes disabling the "Token Expiration Time Override" or setting a really long expiration time solves the problem it introduces a security risk. As the token never expires it is always valid, this means if it ever gets compromised, it will be valid indefinitely and since we are talking about the security of an MDM here, this is not a risk I would like to take. 

This article here gives a pretty decent overview on how tokens regards to token livetimes: https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/