OAuth should ignore port for loopback redirect URIs

[M H]

BitBucket's OAuth implementation https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/

is missing the behaviour in https://datatracker.ietf.org/doc/html/rfc8252#section-7.3

Loopback redirect URIs use the "http" scheme and are constructed with the loopback IP literal and whatever port the client is listening on. That is, "http://127.0.0.1:{port}/{path}" for IPv4, and "http://[::1]:{port}/{path}" for IPv6. ... The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs, to accommodate clients that obtain an available ephemeral port from the operating system at the time of the request.

Please fix this bug.

[Dan Fraser · Accepted solution]

Hi @M H

Thanks for your question, and welcome to the Atlassian Community!

I can confirm that Bitbucket's OAuth2.0 implementation does allow the port to be specified at request time (only for localhost).

When setting up your OAuth Consumer, you'll need to specify your Callback URL as http://localhost. Note that you can have a path specified here if you wish (but this is not strictly necessary). Don't specify a port here either. Bitbucket's backend will handle the port when provided.

When you initiate the OAuth flow, by making a call to https://bitbucket.org/site/oauth2/authorize make sure that you include the fully derived redirect_uri query param in your request.

eg:

https://bitbucket.org/site/oauth2/authorize?client_id=CLIENT_ID&response_type=code&redirect_uri=http://localhost:12345

Please note, that the query params in the above example should all be url encoded.

Hope this helps,

@Dan Fraser 

[M H]

Thanks for your reply. So localhost works but not 127.0.0.1? This is still a bug because the OAuth RFC says https://datatracker.ietf.org/doc/html/rfc8252#section-8.3

While redirect URIs using localhost (i.e., "http://localhost:{port}/{path}") function similarly to loopback IP redirects described in Section 7.3, the use of localhost is NOT RECOMMENDED. Specifying a redirect URI with the loopback IP literal rather than localhost avoids inadvertently listening on network interfaces other than the loopback interface. It is also less susceptible to client-side firewalls and misconfigured host name resolution on the user's device.

@Dan Fraser please could you open a bug?

[Dan Fraser]

@M H , instead of raising a bug, I've done you one better.

I've patched the code to allow the port to be specified at runtime on 127.0.0.1 and the functionality should be available now in production. Note that the existing behaviour still works for localhost, as we have to continue supporting this. We have many consumers setup with localhost as their redirect_uri.

Can you test the functionality again, and confirm that your issue has been resolved? Thanks again for reaching out and bringing this to our attention!

[M H]

Thanks @Dan Fraser that works now.