REST API behind SAML with 3-Legged OAuth

We have 3-legged OAuth working to access the REST API for Confluence Server / Cloud. Unfortunately for our clients using SAML, when we issue the API call to fetch the request token (see https://developer.atlassian.com/cloud/jira/platform/jira-rest-api-oauth-authentication/), our servers receive a 302 redirect to authenticate via SAML.

What is the recommended way to handle REST API calls behind SAML? How unique are the flows depending on SAML provider?

Thanks and apologies in advance as I’m not very familiar with SAML.

1 Like

[bump]

Would appreciate any advice from anyone familiar with dealing with SAML + Atlassian APIs.

Which endpoint redirects and for which hosting model? Is it /plugins/servlet/oauth/request-token? And is it Cloud or Server (different SAML-support implementations)? From my experience, SAML is different enough from provider to provider, that it’s not worth doing. If the request-token endpoint is protected, then I’d consider it a bug.

1 Like

This particular case is for Server. It is the request-token endpoint.

For now we decided to work around this issue by requiring an exception be made our customer’s SAML / firewall. Thanks for your help!

FWIW, this happens with the SAML connector build into JIRA Data Center.

We have a similar issue with SAML logged users.

They are not able to request “/rest/api/2/issue/createmeta” endpoint. When SAML login redirect is disabled they can request the create meta with no issues.

Another thing that is worth mentioning, users connected through SAML do not appear as logged in users and their logins are not counted to the user access count.

Any hints on how to debug this would be appreciated. Thanks in advance.