Bitbucket Server OAuth creates new access-tokens each time

Rodrigo Fernandes_5601ka

When using the Bitbucket Server OAuth 1a process my app is creation one token in the user account per each auth.

 

Usually in Bitbucket Cloud also with OAuth 1a if I send a user but he already has authorized my app Bitbucket Cloud send the user back without re-creating a new token.

 

Why is Bitbucket Server behaviour different? Can I be doing something wrong?

Rodrigo Fernandes_5601ka

After reaching support I got this answer:

Hi Rodrigo,

Greetings from Atlassian Support!

In this issue, I understand that your application is using the OAuth implementation in Bitbucket Server to authenticate and login users – and Bitbucket Server is creating a new token every time the same user goes through this process rather than returning an existing token.

First of all, I would like to clarify that Bitbucket Server and Bitbucket Server – are two separate different applications, so there may be features on Bitbucket Server which is very different with the Cloud, and vice versa.

So in Bitbucket Server, the implementation of OAuth is used as part of Application Links and was never intended to be used as an authentication mechanism, like how your application is using it. This piece was built to authenticate users from one application to another where the users login to each application independently (via LDAP or some other means) and then perform the OAuth dance for authorization. We expect OAuth requests to be made on behalf of an already authenticated user.

There is an improvement request for automatic authorization processing with can be viewed here: https://ecosystem.atlassian.net/browse/OAUTH-346.

Additionally, we do have an existing feature request to allow token based authentication as below:

• BSERV-2722 - Token based HTTP authentication

As mentioned on the feature request ticket, in Bitbucket Server 5.5, the Personal access tokens feature was introduced, where users can create a token with limited scopes (e.g project and repository read) and use them for authenticating REST calls, git operations and integrating with other applications – so you may want to look into this feature to see if that suits your needs and if that can be implemented as a workaround

Please vote and watch the case so that your opinion on this issue may be heard by our development team, comments are also welcome. The feature will be addressed in accordance to our new features policy - Implementation of New Features Policy

Cheers,
Vivian