Atlassian (Jira) smart links may not work when SAML SSO is enforced and no existing OAuth app is configured
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
A GitLab Customer (internal link) has recently shared information on Smart Links which can be used in Jira to show the status of GitLab merge requests and issues, such as:
The customer identified that after enabling the setting SAML SSO enforcement for their top-level namespace, they began to see conflicting results:
- Some users would see the link with the text:
SAML sign-on for <namespace> - GitLab - Some users continued to retain the 'smart link' functionality, and can still see the status of merge requests and issues.
From further investigation, this appears to be tied to whether the user has been prompted to and has created an OAuth application for "Atlassian Links", likely before SAML SSO was enforced. It seems that users that already have this application configured retain their access through smart links (which use the user's oauth token), while those without the application configured see the SAML sign-on link, and have no direction to connect a GitLab account to resolve this behaviour.
To provide further context, here are several different examples:
| Image | Description |
|---|---|
 |
SAML-SSO not enforced, no OAuth Application configured. The user is prompted to 'Connect your GitLab account', which directs via id.atlassian.net to GitLab.com to register a new OAuth application titled "Atlassian Links". |
 |
SAML-SSO not enforced, OAuth Application configured. On page load, Jira will make API calls using the user's OAuth token to check the status of the MR or Issue. |
 |
SAML-SSO now enforced. The existing OAuth Application remains configured. Existing links and new links continue to work, likely still using the user's OAuth |
 |
SAML-SSO remains enforced. OAuth Application has been revoked. The URL remains the same but the Atlassian URL crawler has likely followed the 302 redirect and landed on the sign-on page. Note that there is no prompt to connect a GitLab account to configure Smart links. |
Steps to reproduce
As described above, this can be reproduced with an Atlassian account and Jira Cloud instance. Support Engineers have access to a shared cloud instance. A top-level group on GitLab.com is also required with the ability to enforce SAML-SSO, so test users must have a SAML identity associated.
- In Jira, add a link to a merge request or issue within the top-level group. Ensure SAML-SSO is not yet enforced. The user should receive a prompt to connect their GitLab account.
- Confirm the link takes the user to GitLab.com, requesting they authorize "Atlassian Links" and continue. On page load, the user's oauth token will now fetch and show the status of merge requests and issues using smart links.
- Enable SAML-SSO for the top-level group. Refresh Jira to confirm the user's oauth token is still fetching details on merge requests and issues.
- Revoke 'Atlassian Links' via the user's applications page:
https://gitlab.com/-/user_settings/applications. Confirm that upon page reload all previous smart links now show aSAML sign-onlink instead. No option exists to 'link' a GitLab account to configure an OAuth application.
What is the current bug behavior?
I think this is on the Atlassian side, where they are perhaps checking the URL for a 'known' URL format that can be used for smart links in GitLab. It seems plausible that the crawler is programmed to follow 302 redirects, so ultimately ends up on the SAML sign-on page, but this doesn't provide context to the user on how they can 'fix' this by configuring the Atlassian Links application.
What is the expected correct behavior?
As redirecting to SAML sign-on is expected in this scenario, we would expect that the Smart Links provide an option to 'Connect your GitLab account' still, even on this 302 redirect. This would improve the usability for the user as they otherwise have no knowledge or access to setup an OAuth application again.
Here's an example I created through browser development tools:
Possible fixes
We may need to consult with Atlassian on what they check for Smart Links to see this resolved.