New OAuth2 tokens are invalid (HTTP 401)

API Feedback
1

We successfully implemented API access with OAuth2 into our Loudly app to grant access to various functionality depending on their subscribed tier some months ago.

Today we experienced that new generated OAuth2 tokens are invalid right after creation. The whole process with login and granting access works and the redirect is called and the server is able to convert the single use code into an access_token (Steps 1-4 in the documentation)
But when we use the token e.g. with the api/oauth2/v2/identity endpoint we get HTTP 401 with the following details:

{"errors":[{"code":1,"code_name":"Unauthorized","detail":"The server could not verify that you are authorized to access the URL requested. You either supplied the wrong credentials (e.g. a bad password), or your browser doesn't understand how to supply the credentials required.","id":"88803365-a219-4291-a040-d7417ed5b35d","status":"401","title":"Unauthorized"}]}

This is rather strange as nothing on the server nor client side was changed. The problem could be reproduced with more than one account and also have first user complaints.

I also tried to explicitly add scopes (“identity identity.memberships identity[email]”) and they were displayed on the Patreon grant page as additional bullet points but no effect on the problem.

I also tried use include=memberships instead of include=memberships.currently_entitled_tiers when calling the identity as I saw the change in the GIT-history of the wordpress plugin but without any effect on the result either.

2

Tokens may have expired or soft-deleted due to any reason. Does the situation recur if you create the token again?

On the topic of scopes: You still may be requesting an include or a resource which you did not ask the scopes for while you were requesting the token. This could cause 401s.

If you have used the WP plugin as an example, using the scopes it uses in creating the login/flow links and testing with the call it uses to get identity resource afterward, may help debug this issue.

Just search for ‘scope’ and you will see where the login/flow links to get the token are generated. You can construct the final link from the code there. (Unless if you prefer installing the WP plugin somewhere and just copy/paste the login link from WP login page).

3

PHP library has examples that are easier to read if you would prefer that:

The readme includes an example whereas examples folder has more examples:

4

Hi Codebard,
Thanks for the quick response! Unfortunately the do not helped me to solve the problem. To your question and as further explanation:

  • The situation appers only for newly created tokens. Token that have been created some time ago seem to keep working. So it seems not have to do with expiration of tokes.
  • We already use the PHP SDK and to be said again: we already have/had a well working implementation. The whole process worked well for months and now stopped working without any change on our side. (neither the app nor the server was changed for my best knowledge)
  • We initially used no explicit scope parameter as the default value seemed to include all necessary permissions that we need to find out wether ther user is subscribed to one of our projects tiers or not. BUT now I also tried to explicitly specify the scope here and even extend the scope witht the following result:
    ** the additonally requested permissions are displayed in the grant screen as addtional bullet points. (so where the user is asked to grant access to Patreon or now)
    ** but even with the explicitly requested and extended scope parameter I get 401 alll the time when I try to use the delivered token.
5

Additional learning: I did some more experiements and found that if I do use the refresh_token to re-create the access_token then I get a valid access token. (step 7 in your OAuth documentation: https://docs.patreon.com/#step-7-keeping-up-to-date)

This gives us the opportunity to do a work-around. But it is unexpected and wrong behaviour I guess if fresh access_tokens are instantly expired after user has granted access. So it would be meaningful to find out why this happens anyway.

6

Ill try to reproduce this and let you know. In the meantime note that if there is any code that auto-refreshes tokens in your app and it is kicking in without token needing refresh but not saving the refreshed token that may cause a situation like this as well.

7

Thank you again. Please let me know if I can support your attempts to reproduce in any way.

Of course we will store new tokens (both access and refresh) after retrieving them from the refresh call.

8

We currently have it working again. But unfortunately I cannot clearly confirm that it was or was not on our side. I do not have direct access to our servers but to the clients so need some more information from me colleagues. Would feel better to have exactly understood the problem.
I will let you know if there are any more insights that seem meaningful for you.

Thanks again for all the response so far.

9

This may have been a hiccup on Patreon api side. If it recurs, please let us know.