You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Recently we have been encountering some issues with API tokens:
- When we revoke a token manually from the API tokens page, it can take a long time (20min) before the token actually expires. Is this delay normal?
- When we try to fetch projects or project information using an expired token, we get a 200 with an empty array where we used to get a 401 that allowed us to handle the specific case and tell our users they needed to make a new token. Is this intentional? Is there any way for us to check the token validity somehow? (It might be the case that a user simply has no projects. We can't tell the difference between that and an expired token).
Thanks in advance,
Hello @Denis Hacquin ,
For the token revocation maintaining a connection for a short period, this token is managed through the Identity system which has various levels of replication tasks required and needs to propagate through the authentication system on an interval to not overload the system with requests, and some of the items are cached in the user session which is the reason for the delay. The timetable on revoking a API key is mentioned on the "Admin API Key" documentation noting:
Revoking an API key is permanent. It may take up to 10 minutes for a revoked key to stop working.
But, you can manually force the replication tasks by logging off from the user and any changes should take effect and replicate immediately on the users next log in.
As for the 200 HTTP code instead of the 401, it depends on the endpoint that your users are getting the response from. The REST API documentation should specify what they can expect to get back if they provide an expired token.
There is a good example in the following section:
The “Get avatars” method allows anonymous access, so it will return a 200 and no data if you are unauthenticated. It specifies this in the documentation with the phrase “This operation can be accessed anonymously.” and "Permissions required: None."
And the endpoint for "GET /rest/api/3/project" is another with the "This operation can be accessed anonymously." notation, as the value returned is null as they successfully returned everything they have access to view via the permissions of anonymous which is nothing at all.
As for telling the difference between an expired token and a incorrectly formatted request gets a bit tricky other than familiarizing themselves with the expected responses, and noting the difference of in app data results compared to the api response, as authentication related error responses are obligatory by design for security purposes, to prevent exposing any information that could be used to collect additional data about the system.
When referring to the API tokens you generate at https://id.atlassian.com/manage/api-tokens , there is no expiration date on those unless you manually revoke the ones you don't want to use anymore or mark the account that owns the token inactive. So if your users are constantly revoking tokens, it might be a good idea to enforce a methodology of using a good naming convention on the labels.
When you're using the Admin API Keys, these items have a 7 day default and 1 year max lifetime, fo familiarizing uses with the expected lifecycle of the token should be adopted into practice.
The problem is, that:
The behaviour should be same - API should return 401 for any invalid API token, does not matter is it was revoked or used with wrong email.