RFC-34: Forge remote - retrieving new access tokens at any time

General Request for Comments (RFC)
, ,
17

Please do allow me to argue here the following alternative solution:

  • An OAuth based solution in which apps will get a client_id and client_secret per app (not per-instance). This is a well established pattern that developers understand. They know that they need to keep these a secret and can put them in environment variables.

    For added security, you can force us to rotate client_secret every X period.

  • Apps can retrieve ad-hoc short-lived access tokens using a longer-lived refresh token.

    For added security, requests should come from an approved domain/IP list and the response payload can be encrypted using the client_secret

  • Require access tokens / refresh tokens to be signed/encrypted using the client_secret when making request, which would make the access tokens useless without also having access to the client_secret (and tell people not to store client_secret together with refresh token).

  • The refresh token itself could also be short-lived (24h for instance). Apps will do a single call once a day to get a new refresh token. If they fail to do that, you can have the whole async token flow described here to a known endpoint to get a new refresh token.

    For added security, you can also deliver a new refresh token with each request for a new access token

  • Resume work on the granular scopes in order to limit access of the access token (app developers also want this, we do not need full access!)

The clear benefit of using this flow is that it is well known and understood by developers, limiting the possibility of people making strange choices on how to deal with the tokens. They understand OAuth, and if they don’t there is a plethora of online resources to help them.

There are also existing libraries that can help implementing the OAuth flow and dealing with refresh tokens, limiting the amount of boilerplate code written by developers to deal with this custom flow.

Please stay with industry best practices. There is a reason they exists. The data Atlassian stores is not more/less important than what other companies store and they also rely on access tokens / refresh tokens. Providing 3rd party access is inherently insecure, there will always be a level of trust involved (and lawyers creating unreadable agreements that limit liability).

5 Likes