OAuth2 Redirect URI not registered for client - but nothing changed

For six months our OAuth2 redirect URI was simply https://app.ourdomain.com and when we would send our users we sent https://app.ourdomain.com/auth/atlassian_oauth2/callback and all was well.

In the last two days we found that our users were experiencing a hiccup when requesting access. They were getting an error that the client id was not registered for the redirect url we were sending.
The tokens we already had could refresh just fine, but we could not get any new credential grants.

I changed our redirect to include the path and things started working again.
Anyone know what happened?

Incidentally there is an SO question that seems to be in reverse - they had the full path but that stopped working and then it would only work if the redirect was simply the domain. Jira oauth2 App client_id not registered for redirect_uri

Hi Bart,

I am not seeing anything in the latest Changelogs in regards to changes to OAuth. Might I suggest opening a ECOHELP bug ticket and provide more details with any appropriate logs so the support engineers can help further?



Cool! That was quick! Thanks!

1 Like

I’m having the same problem. Nothing changed in my code for months and suddenly I’m getting this message when I’m trying to get the access token.

redirect_uri is not registered for client: https://xxxxxxxxx.net"}

@BartPalmer and @AleksandarArabadjiev,

While I understand that a change in behavior is always confusing, I think you are asking us to explain an undocumented and unsupported behavior. The section on Enabling OAuth 2.0 (3LO) that explains how to register a client in the developer console explains:

  1. Enter the Callback URL. Set this to any URL that is accessible by the app. When you implement OAuth 2.0 (3LO) in your app (see next section), the redirect_uri must match this URL.

Is there a reason you can’t fix the OAuth client in the developer console so the URLs match?

1 Like

Thanks for chiming in.
I did change the Callback URL to match the full path and things are working now.

Just wondering why it was working for so long with only the scheme and domain parts - what changed in the last three months that made it work only with the full path?

Oddly, all the tokens and refreshes continued to function normally with the full-path URL in the call, but only registered scheme://domain in the app settings. In other words, only new connections were rejected. That seems inconsistent (and made it harder to pinpoint), can you help me understand, @ibuchanan (or anyone)?

At any rate, things are working again as long as scheme://domain/path are exact matches.


We are rolling out a back-end change, so some of the compute and storage behind the OAuth 2.0 implementation have changed. The intent was that clients would keep working, with no disruption to existing authorizations. In your case, it seems the old implementation was not as “picky” about all the specified URLs and the new implementation is. Back-end changes like this are often not reported in changelogs because they do not affect conforming clients. Still, we do apologize for the inconvenience.

@ibuchanan - I feel a TON better knowing something has been changing. Thanks.

1 Like