Today we have launched some improvements to the API to allow you to more easily have programmatic access to your project data. Bearer tokens are an extension to the existing OAuth negotiation that makes it vastly easier for your program to access the API. Additionally, the API can now be used with the project data export launched in September to easily make regular backups of your project’s data, as well as now being able to install new tools for a project programmatically.
Bearer Tokens
On the OAuth tab under your Account settings, you can now generate a bearer token for any registered OAuth application. These tokens are pre-negotiated, so your application doesn’t need to deal with the multi-step OAuth verification process and can just include the token in the access_token parameter to any HTTPS GET or POST request to the API. Note: because these tokens grant all of the access rights of your account, you should protect them carefully and revoke any that you are no longer using. More information on using bearer tokens, including example code, is available on the wiki.
Project Admin API
The project data export feature can now be accessed via the API, so you can schedule a project export, check the export’s status, and download the exported data, all programmatically. There is even a drop-in script ready to do all of these steps for you.
Additionally, you can now install new tools, such as new repositories or ticket trackers, into your project via the API. More information is available on the wiki.
OAuth was introduced as a more secure authentication process. So doesn’t the bearer token undermine that security?
Bearer tokens are slightly less secure than the full OAuth workflow, mainly because they don’t also require the client ID and secret and thus the request is not signed. However, to balance that, they can only be used over HTTPS / SSL and only tokens specifically generated to be bearer tokens can be used in that way. They still require manual user approval and can be revoked if exposed or no longer in use. Care must be taken to not expose the bearer token, just as with the client ID, secret, and access token from the full OAuth workflow, but they serve as a compromise for situations when user interaction is not ideal without having to use your account login password.
intel352 Bearer tokens are slightly less secure than the full OAuth workflow, mainly because they don’t also require the client ID and secret and thus the request is not signed. However, to balance that, they can only be used over HTTPS / SSL and only tokens specifically generated to be bearer tokens can be used in that way. They still require manual user approval and can be revoked if exposed or no longer in use.
Care must be taken to not expose the bearer token, just as with the client ID, secret, and access token from the full OAuth workflow, but they serve as a compromise for situations when user interaction is not ideal without having to use your account login password.