Closed weswalla closed 5 months ago
If we stick with OAuth 2.0, my proposed solution is the following:
This will be a continuous loop running as long as the user grants twitter access.
I think the refreshToken
might be valid even after the original accessToken
expires. We will have to test this.
If this is the case, the refresh flow can be implemented directly in the TwitterService
getUserClient
method.
Also, a note: the accessType
'read' option in OAuth 1.0 was not effective when I tried it. Even if you configure it, the permissions requested include posting in the name of the user.
With OAuth 2.0 for the twitter API, the access token is valid only for 2 hours after being issued and there is no way to extend the expiry date. The provided refresh token is supposedly valid for 6 months, so we will need to implement logic to check if the access token is still valid (or check the response type) and refresh accordingly.
This will certainly increase our total requests which some devs have expressed is unfeasible for their apps and have downgraded to OAuth 1.0:
There are other tools out there that can help us manage these access tokens and refresh tokens, like: https://github.com/superfaceai/passport-twitter-oauth2/tree/main
Alternatively, it does look like it is possible to specifically request read or write access with the oauth 1.0 flow: https://devcommunity.x.com/t/how-to-request-read-and-read-write-permissions-on-the-same-app/170242/9 which provides an access token that doesn't expire.
The access type seems to be supported in the
twitter-api-v2
module as well:Though from the forum discussion there may be some limitations in using oauth 1.0 for login (authentication) along with authorization: