OAUTH 2.0 - 404 Error When Directing User to the authorization URL

[Bill Bloebaum]

We're seeing intermittent issues with our redirect to the OAUTH authorization endpoint when a user has authenticated to JIRA in the past with that particular browser. The authorize endpoint is returning a 404, but only when the user has logged into JIRA at a different point in time for that browser.

Summary

We are seeing this error on the first step of the OAUTH 2.0 flow with a properly formatted URL.

From the docs: https://developer.atlassian.com/cloud/confluence/oauth-2-3lo-apps/#1--direct-the-user-to-the-authorization-url-to-get-an-authorization-code

https://auth.atlassian.com/authorize?
  audience=api.atlassian.com&
  client_id=YOUR_CLIENT_ID&
  scope=REQUESTED_SCOPE_ONE%20REQUESTED_SCOPE_TWO&
  redirect_uri=https://YOUR_APP_CALLBACK_URL& 
  state=YOUR_USER_BOUND_VALUE&
  response_type=code&
  prompt=consent 

What I'm seeing is that when a user is redirected there they are getting met with a 404 Whitelabel error page:

---

---

What's strange is that if I delete this cookie and then refresh the page I see the correct linking/permissions page.

1. Delete this:

2. Refresh the page

3. The Atlassian site first redirects the user to an "https://id.atlassian.com/login/authorize?continue=..." URL with a callback to the /authorize endpoint which then properly redirects to the "https://api.atlassian.com/oauth2/authorize/server/consent..." endpoint

How can we ensure that redirecting our users to the /authorize endpoint will cause a login refresh or ignore this cloud.session.token cookie in order to prevent seeing this 404 page?

Thank you for any insight.

[Bill Bloebaum · Accepted solution]

For future travelers:

The issue turned out to be a quirk of the routing resolution. Where our request had a trailing slash "/authorize/?..." rather than "/authorize?..."

It had been working for a while without issues until last week. So perhaps recently a config might have gotten changed on the Atlassian side to be stricter on direct routing which no longer parses that trailing slash version as a valid route.

The cookie deletion was a clue because the Atlassian login service trims and sanitizes the callback URL and removed the trailing slash, leaving only the question mark. Atlassian's server-side handling doing that trimming made the forced-login flow work.

Example continue parameter from the Atlassian login:

https://id.atlassian.com/login/authorize?continue=https%3A%2F%2Fauth.atlassian.com%2Fauthorize%3Faudience%3Dapi.atlassian.com