Application specific passwords or tokens (BB-14202)

Issue #11774 resolved
Marcus Bertrand
staff created an issue

When Bitbucket and Atlassian release two-step verification (two-factor authentication), some applications that rely on basic authentication may no longer work as expected. While Bitbucket recommends that third-party application developers switch to using OAuth, there are still many applications where https may be the only option.

Application specific passwords would allow users to create a password that would allow them to use Git, Mercurial, and the API over https as needed.

Official response

Comments (46)

  1. Alexander Rinass

    What is the advantage of app-specific passwords over OAuth tokens?

    Last time I checked, Bitbucket supports using OAuth tokens for HTTPS Git/Mercurial access and API access.

    So, while it would provide a useful option to create Access Tokens managed by the user, it does not seem to be mandatory for third-party apps.

  2. Erik van Zijst

    Vladimir, we are currently busy implementing application passwords. However, as Alex points out, OAuth 1 and 2 are available and meant for things like this, so lack of app passwords shouldn't have to be a blocker.

  3. Steven Anderson

    I'm here because I bumped in to the issue where SourceTree doesn't allow me to add/browse a hosting account (i.e. bitbucket) because I enabled 2 step verification on bitbucket. Is there another way to do this with 2 step verification enabled on bitbucket?

  4. Pysis

    Another SourceTree user here. @Steven Anderson, I am experiencing the same issue, and even a painful crash with a newly added BitBucket account into SourceTree, working over SSH, with my normal username and password, trying to list the remote repositories. I did find this resource, which seems to imply that is the only functionality that does not work, but the rest does. I haven't gotten past this point, but maybe if you had an already cloned repository on disk, that has its remotes set to BitBucket, you would then connect to SourceTree, and it would work.

    Here's the link:

    Besides that, I would guess disabling 2 factor authentication would provide a stop-gap measure, although that does pose a security risk and is not recommended.

  5. Morgan Estes

    I ran into this today while setting up PhpStorm (IntelliJ) integration, which only allows username + password authentication. Short of forking the function and rewriting it for OAuth, there's nothing I can do to get it working as long as I have 2FA enabled on Bitbucket.

    Solutions that work with other providers are varied, but here's the ones I've had success with:

    • App-specific tokens (like Github provides)
    • API tokens (enabled for teams, but not individuals)
    • Adding the authentication code along with the password (PayPal does this; not feasible with rolling TOTP codes, but maybe with a recovery code)

    Anyway, those are some unsolicited thoughts on this. I'm voting/watching and hoping for a good solution soon.

  6. NathanL

    Any update on the schedule for this?

    Or, otherwise 2FA support in SourceTree? Adding repos manually isn't ideal when you have a lot of them.

  7. Baron Roberts

    I would like to understand how OAuth is in any way practical for command line apps that use the BitBucket API, especially when those apps are behind a firewall. The only OAuth scheme that appears usable by command line apps is the Credentials Grant scheme but that flies in the face of 2FA and is appropriately disallowed by BitBucket when 2FA is enabled. So I am left waiting for application specific passwords in order to enable 2FA and retain the use of the BitBucket API in my command line apps.

    Given the importance of application specific passwords for all BitBucket users with command line API applications, is there any roadmap or timeline that can be shared with the user community?

  8. Baron Roberts

    It has been over a month since my last request for an update on this critical limitation in BitBucket's 2FA implementation. Please provide an update even if it is to say that there is no schedule for this feature.

  9. Andy Fragen

    Is there a format for how this is used via CLI?

    GitHub supports adding the token to the end of the URI as &access_token=xxxxxxxxxxxxxxxxx

    Does this app password function similarly? Is there some documentation regarding it's use?

  10. Benjamin Echols

    @Pavel Sher no, there's intentionally no API for this feature because we're trying to make all auth methods scoped. If we were to allow an app password to be added via the API, we'd need to do something like limit the scopes to the same scopes of the calling token. Otherwise you can have an OAuth token that has whatever scope is needed to add an app password and then add an app password with all scopes, bypassing the whole scope permission model.

    It's definitely something we could reconsider, but we don't have any plans to add an API for app passwords right now.

  11. Benjamin Echols

    @Andy Fragen Yes, you can use the app password in place of your account password, but use the same format otherwise - the app password must be included in the Authorization header using Basic auth.

    We'll definitely be adding full docs when we promote app passwords to general availability, but we wanted to let you start using them ASAP.

  12. Pavel Sher

    Then this is a bit useless for those who provide integration with Bitbucket from other software. GitHub, for instance, offers ability to create a token which does not expire. This is very convenient as such a token can be used as password and stored in software integrating with GitHub without compromising original password. With Bitbucket (correct me if I am wrong), software which integrates with it has to use refresh tokens each time which makes the whole integration more complex then needed, without benefits. Since refresh token can be used to obtain new access token, it's not better, not secure then GitHub non expirable access token. So, I truly hoped Bitbucket would provide a way to generate such a token for a user via REST API.

  13. Benjamin Echols

    @Pavel Sher not quite: once the user creates an app password via the UI, including setting the scope, the app password can be used instead of the user's actual account password to authorize requests to Bitbucket from an external application. There's no need for the integration to refresh a token for each request to Bitbucket.

  14. Pavel Sher

    But user have to create this password himself, right? There is no way for a software integrating with Bitbucket to generate this password on behalf of the user, or am I missing something? App passwords are definitely useful, but workflow for user could be simpler if there was an API to generate these passwords.

  15. Brian Rozmierski

    @Pavel Sher I'm sorry, but I disagree. If an app is going to generate a method by which it will have permanent access to my account, that is not something I believe it should be able to do without my affirmative consent. An API to generate app-passwords is not appropriate.

  16. Georg Walther

    Thank you for making this available. I attempted generating an app password for Bitbeaker (Android app), however providing my bitbucket username and the generated app password did not allow me to log into Bitbeaker - I only got an "invalid username / password etc." message.

    Did anyone get this to work - in particular with Bitbeaker by any chance?

  17. Andrew Swan

    Hi Ben,

    Congrats on the public release of app passwords!

    In the blog post, you might want to change the words "to just do that" to "to do just that", otherwise it sounds like it's limiting what you can do.



  18. greateagle

    I'm a little confused about why an app password is any more secure than passing the user/pass as basic auth.

    A packet-sniffer could still easily walk away with your app password, and use it for bespoke api calls (within the permissions scope of that password of course).

    So, am I missing something? What exactly is the advantage?

  19. Jaffa

    App passwords are useful as not all software supports 2FA login, in software that doesn't support it you just simply can't use it without disabling 2FA account-wide without this feature.

  20. RichardS

    That and they can be revoked without you having to change your account password. And if used properly (I.e. one password per application) you should easily be able to spot which one leaked which may well give you a hint as to what might have gone wrong (What computer, network etc is compromised).

  21. Daniel Bennett staff

    App passwords have the following benefits:

    1. Isolation -- you can have one password per integration / application and manage leaks better.
    2. Scoping -- the app password creation screen allows you to set which permissions the app password should receive so you're not giving away all the keys at once.
    3. Limited functionality -- even with all scopes present, you cannot log into the web UI with an app password. You also cannot create additional app passwords, SSH keys or OAuth tokens with an app password. This makes it harder for someone to use an app password to create a second back door in your account.
  22. Log in to comment