compatibility with Twitter v2

[geduldig]

Can this package be made to work with Twitter v2?

[jnv]

Hi, this is the reason why this package exists. This strategy targets OAuth 2.0 which works only with v2 API (while API v1.1 uses OAuth 1.0a). Or did you run into an issue using this strategy with v2 API?

[geduldig]

Hi - I ran into a few issues. To begin with, I noticed these two default options in the Strategy contructor:

options.tokenURL = options.tokenURL || 'https://api.twitter.com/oauth2/token';
this._userProfileURL = options.userProfileURL || 'https://api.twitter.com/1.1/account/verify_credentials.json';

I believe they are both v1.1 endpoint URLs, and the corresponding v2 URLs are:

tokenURL: 'https://api.twitter.com/2/oauth2/token'
userProfileURL: 'https://api.twitter.com/2/users/me'

Any thoughts about which endpoints are appropriate?

Jonas

[janhalama]

Hi Jonas, this package actually uses v2 URLs as default options. Look at the https://github.com/superfaceai/passport-twitter-oauth2/blob/main/lib/strategy.js file content.

Jan

[janhalama]

Have a look at our demo project https://github.com/superfaceai/twitter-demo which uses superfaceai/passport-twitter-oauth2 package to authenticate with Twitter v2 API.

[geduldig]

I see the issue. I am using a different package also called passport-twitter-oauth2. This one by @hewman. I just noticed that the install command for the @superfaceai package is npm install @superfaceai/passport-twitter-oauth2. I'll switch, hopefully with better results.

[geduldig]

Now that I have the correct package installed things are working. I get the access_token and refresh_token, and I'm able to use V2 search. I'm still a little confused about app-based authentication and user-based authentication. This question probably belongs in the Twitter forum, but if it's easy for you to explain, I'd appreciate it.

I'm looking at the docs here: https://developer.twitter.com/en/docs/authentication/oauth-2-0/user-access-token. It appears I'm supposed to use the access token for the bearer token in order to make requests on behalf of the user. But isn't bearer authentication a way of authenticating on behalf of the app? Doesn't this get you app rate limits and not user rate limits?

Jonas

[janhalama]

Hi, bearer token authentication can be used for authenticating on behalf of both user or app. You are right that access token is passed as the bearer token in authorization header. The access token is result of OAuth2 authentication flow. OAuth2 Client Credentials Flow's access token authenticates you on behalf of the app. OAuth2 Authorization Code Flow with PKCE's access token authenticates you on behalf of the user.

[geduldig]

Thank you for confirming this for me.

[geduldig]

Closed this a little too quickly. One more question: how do we use refresh_token with this package? And what is the use case?

[jnv]

You can use refresh token to obtain a new access token after the original access token expires. The refreshing process is explained here in step 5: https://developer.twitter.com/en/docs/authentication/oauth-2-0/user-access-token

Refresh + access tokens are pretty standard as with any other OAuth 2.0 API, but I've found Twitter's implementation to be particularly strict:

• Access tokens expire after 2 hours
• Refresh tokens also expire relatively soon, from my testing it was in a matter of days (while with other providers it's in months)
• Refresh token can be used only once, you get a new one upon refresh with a new access token.

Passport strategies typically aren't concerned with refresh tokens, including this one. But there is passport-oauth2-refresh which acts as a sort of wrapper for existing OAuth 2.0 strategies. We use our OneSDK for refreshing tokens with this profile: https://superface.ai/oauth2/refresh-token

[geduldig]

Thank you for those helpful links.