Important Update Effective February 1, 2024!
Due to recent changes in Jira and Confluence, we've made the tough decision to discontinue the OpenID Connect (OIDC)/OAuth app and no longer provide new versions for the newest Jira/Confluence releases as of January 31, 2024.
This is due to some necessary components no longer shipping with Jira/Confluence, which would require some extensive rewrites of the OIDC App.
Impact of the Changes to the SameSite Cookie Flag Default Behavior in Chrome
Google is planning to enable SameSite flag cookie enforcement (https://web.dev/samesite-cookies-explained) to its Chrome browser (currently planned for version 80, due in early February 2020) and for beta users earlier (https://www.chromestatus.com/feature/5088147346030592).
Problem Description:
This effectively breaks reauthorization via POST binding after the the Atlassian product session ends for IdPs that currently don't set SameSite=None on their session cookies.
Cause:
Because the new default behavior is to assume SameSite=Lax for every existing cookie, the IdP's session cookies are not sent during cross-origin POST requests, which is basically how SAML POST binding works. This means that when our plugin has the user's browser send a POST request to the IdP, the session cookie that the user has on the IdP isn't sent with this request. This causes the IdP to think think that the user is not logged in and prompts them for their credentials, even if the user has already logged in on that day.
Solution:
Update your Identity Provider to a version that automatically sets the SameSite=None flag.
If updating your IdP is not an option at the moment, scroll down to find some mitigation techniques.
IdP Vendor Support of SameSite=None cookie option (as of 2020-01-15)
| IdP | Status | Link | Version | Note |
|---|---|---|---|---|
| AD FS |  | https://support.microsoft.com/en-us/help/4522904/potential-disruption-to-customer-websites-in-latest-chrome | ≥ January 14, 2020 | Update required |
| Azure AD | | https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new#november-2019 | November 2019 | No change necessary |
| Okta | | https://developer.okta.com/docs/release-notes/ | 2019.10.0 & 2019.10.2 | No change necessary |
| GSuite | | No change necessary | ||
| Ping Federate | | https://support.pingidentity.com/s/article/SameSite-cookie-support-in-Ping-Identity-products | Several; see Link | Configuration change necessary |
| SecureAuth | | https://support.secureauth.com/hc/en-us/articles/360038330652 | 9.1+ | Configuration change necessary |
| SimpleSAMLphp | | https://simplesamlphp.org/docs/stable/simplesamlphp-changelog#section_9 | 1.17.3 from July 2019 | Configuration change necessary |
| Shibboleth | | https://wiki.shibboleth.net/confluence/display/DEV/IdP+SameSite+Filter+Implementation#IdPSameSiteFilterImplementation-Configuration | 3.4.5 from September 2019 | Configuration change necessary |
| Ping One | | https://support.pingidentity.com/s/article/SameSite-cookie-support-in-Ping-Identity-products | Vendor says they will update in time and since it's a cloud product, no action needs to be taken | |
| Keycloak |  | https://issues.redhat.com/browse/KEYCLOAK-12125 | Keycloak has an additional step between receiving the SAML request and processing the login, which means it's not susceptible to this bug. If you use Keycloak with OIDC with session management, you still need to wait for the linked bug report to be fixed. |
Mitigation:
Option 1: Set flag at reverse proxy / load balancer
If an update is not yet available for your IdP and if you have a reverse proxy or load balancer in front of your IdP, you might be able to configure it to set the SameSite flag. The exact technique will vary based on the software you're using. nginx example
When you implement this option, please note that older Safari versions on macOS and iOS devices interpret this setting wrongly and need to be exempt from this flag: https://bugs.webkit.org/show_bug.cgi?id=198181#c24
Option 2: Use Redirect binding in SAML
If your Identity Provider supports Redirect binding as well, you can use another mitigation technique:
Changing the binding type to REDIRECT seems to fix this at the moment on our site, since the new default behavior doesn't impact the 302 redirects used in REDIRECT binding. Note that for some IdPs, changing the "Protocol Binding" setting to "None" or "Post" was also necessary.
To change the binding type:
- Navigate to the SAML SSO Configuration page
- Click on Identity Providers tab in the middle panel
- Scroll down to the Binding settings
- Change the Login Binding to REDIRECT
- Save the configuration
Option 3: Enterprise controls in Chrome
See https://www.chromium.org/updates/same-site for information on how to create an exception for your site if you're using enterprise controls in Chrome.