Personal Access Token in Confluence - Not working even when following the Developer Documentation
Asked by Joachim Schneider:

Dear All,  
I created a Personal Access Token for my regular user, not Admin. Copied the Token and tried connecting via curl as described on the page "Using Personal Access Token" in the documenation:  

    curl -H "Authorization: Bearer <yourToken>" https://{baseUrlOfYourInstance}/rest/api/space?limit=10

This results in a 200 OK but without any data as follows:

```
{"results":[],"start":0,"limit":10,"size":0,"_links":{"self":"https://{baseUrlOfYourInstance}/rest/api/space","base":"https://{baseUrlOfYourInstance}","context":""}}
```

Tried it in Python: same result.

If I however log into Confluence in my browser and issue the rest api request, I get the results as expected - in this case a JSON listing of the first 10 spaces accessible for my user. I would like to avoid logging in with credentials from the commandline.

What am I doing wrong? Running Confluence 7.16.5 Self Hosted


Answers:
author: Oday Rafeh
body: Hi [@Joachim Schneider](/t5/user/viewprofilepage/user-id/5182559) ,

It looks like your API request is working correctly, as you're receiving a 200 OK status code. However, you're not getting any data in the response. This might be due to permission settings for your Personal Access Token (PAT).

comments: author: Joachim Schneider
body: Thanks for the insight. I am wondering where I would set permission for the PAT. As far as I understand from the documentation, the PAT should have the same permission as my user. When creating a PAT I cannot select any permissions, just create one. Also it seems that Confluence is unaware of the fact that I did use my PAT. I just discovered that in my settings dialog it says: "Last authenticated: Never" in regard to this PAT. So apparently curl -H "Authorization: Bearer \<yourToken\>" did not go through, which would explain the API answering 200 OK but with no data, as it did not authorize.

![2023-03-29 PAT never used - how.png](https://community.atlassian.com/t5/image/serverpage/image-id/248408iE56E61AAD4CDB6E0/image-size/large?v=v2&px=999 "2023-03-29 PAT never used - how.png")


author: Oday Rafeh
body: Hi [@Joachim Schneider](/t5/user/viewprofilepage/user-id/5182559)

it seems that Confluence is not recognizing the use of the PAT, as indicated by the "Last authenticated: Never" message in your settings.

One potential issue could be with the format of your PAT in the API request. Make sure that you're replacing "\<yourToken\>" with the actual token you generated, without any brackets or other characters. Also, check that you're using the correct endpoint URL for your Confluence instance.

And one thing more as I can see in your request

```
curl -H "Authorization: Bearer <yourToken>" https: //{baseUrlOfYourInstance}/rest/api/space? limit=10
```

You may try to use Basic in place of Bearer like this way :

```
Curl -X -H "Authorization: Basic [base64_encoded_credentials]" \ -H "Content-Type: application/json" \ "https: //{baseUrlOfYourInstance}/rest/api/space? limit=10
```

\[base64_encoded_credentials\] Here You need to encode your token + your email address


author: Joachim Schneider
body: Thanks a lot. I tried the approach with 'Authorization: Basic' even though the documentation clearly states "For the PAT authentication, you should only replace '*\<yourToken\>* ' with the actual PAT. The "Bearer" part should not be changed, nor should you need to inform which user is making the request". I got the expected 404 result. For the "Authorization: Basic".

I did enter the Token correctly without any brackets ( no \<\> either) as displayed in my personal settings.

I also checked the endpoint in the Browser. When I log in via the Browser and type the URL as in the cURL command, I do get the first 10 Spaces visible for my user as a JSON object as expected.


author: Joachim Schneider
body: I created a PAT within Confluence and try to connect and authorize my script with it.

I get a 404 and "authorized":false on the CLI, but the URL works perfectly in the browser, giving me the expected result. I am wondering if a correct answer would include {"authorized":true instead of false. What am I doing wrong? I do follow the developer documentation. Confluence Version is 7.16.5

My code:

import requests  
token = "YayToken"  
myHeaders = {  
"Accept" : "application/json",  
"Authorization" : "Bearer " + token  
}  
confURL = "<https://organizationalURL>"  
response = requests.get(confURL + "/rest/api/content/123456789", headers=myHeaders, verify=False)  
print(f"Status Code: {response.status_code}")  
print(response.content)  
response.close()

I get a

b'{"statusCode":404,"data":{"authorized":false,"valid":true,"allowedInReadOnlyMode":true,"errors":\[\],"successful":false},"message":"No content found with id: ContentId{id=123456789}","reason":"Not Found"}'

In the browser however I get the correct content. Anyone?

comments: author: Paul Woods
body: Did you get anywhere with this Joachim? I'm facing the same issue - I have a customer about to switch off basic auth for apps in confluence data center, and there doesn't seem to be any way to fetch data using personal access tokens.


author: Joachim Schneider
body: Dear Paul, unfortunately not. I had no time to follow up on the issue but all testing went in a direction that it just does not do, what it's advertised to do. When entering an API query in my browser, while logged in, everything works fine, so logging in with password, keeping the cookies and providing the cookies for subsequent API calls via curl will work, but that's exactly what I cannot roll out in LIVE as it will require the users passwords be stored in other places, which is unacceptable. That's where PAT would really come in handy, if they'd do, what they are supposed to do. But until now authorization: false is the answer.

I will try to setup a testsystem and probably have a look at the code in the next few weeks and post the results here.

Sorry I have no solution yet.


author: Ken McClean
body: FYI I just tried it with Joachim's code, and it worked fine for me:  

import requests  
token = "\<token\>"  
myHeaders = {  
"Accept" : "application/json",  
"Authorization" : "Bearer " + token  
}  
confURL = "\<url\>"  
response = requests.get(confURL + "/rest/api/content/12320783", headers=myHeaders, verify=False)  
print(f"Status Code: {response.status_code}")  
print(response.content)  
response.close()  

<br />

Please keep in mind that the token doesn't need to be base-64 encoded or combined with the username, unlike with Basic authentication.  


author: Levy, Jerry
body: Well, I'm hitting it too, with curl (content ID obfuscated, but it is confirmed correct via a browser session):  

curl -H "Authorization: Bearer \<obfuscated\>" -H 'Content-Type: application/json' <https://my-server/rest/api/content/9999999999> \| python -mjson.tool

returns:  

{  
"data": {  
"allowedInReadOnlyMode": true,  
"authorized": false,  
"errors": \[\],  
"successful": false,  
"valid": true  
},  
"message": "No content found with id: ContentId{id=9999999999}",  
"reason": "Not Found",  
"statusCode": 404  
}  

Yet it does not fail with this query (same token), although it doesn't return anything of use:  

curl -H "Authorization: Bearer \<obfuscated\>" -H 'Content-Type: application/json' <https://my-server/rest/api/space?limit=10> \| python -mjson.tool  
% Total % Received % Xferd Average Speed Time Time Time Current  
Dload Upload Total Spent Left Speed  
100 171 0 171 0 0 1526 0 --:--:-- --:--:-- --:--:-- 1526  
{  
"_links": {  
"base": "<https://my-server>",  
"context": "",  
"self": "<https://my-server/rest/api/space>"  
},  
"limit": 10,  
"results": \[\],  
"size": 0,  
"start": 0  
}  

Any good way to troubleshoot why the "authorized" is false? Other ideas?  

Thanks...


author: Levy, Jerry
body: Well, I ginned up a different PAT and it worked. Damned if I know: retried the old one, same length as the new one, double-checked that it wasn't a copy-and-paste error, but the new one is fine and the old one isn't,   
Moral of the story: if one PAT doesn't work, try another one...


Tags: confluence-server

server