Recent changes to Twitter’s OAuth login flow and API endpoints




On September 29th 2017, a change was made to Twitter’s backend OAuth API endpoints which altered the behaviour of the /oauth/authenticate endpoint to match that of the /oauth/authorize endpoint.

This change was made as a safety measure to protect our users, and to ensure that they understand which applications are requesting the use of their Twitter authentication tokens and the permissions that are being granted.


Applications that previously called the /oauth/authenticate endpoint (after a user had signed-in and granted access to their user token via the /oauth/authorize endpoint) will now always show an interstitial screen checking that the user wishes to authorize the application to have access to their user token. This is a change in behaviour - previously, once the authorization was granted once, apps could effectively skip this step in the process by calling the alternate endpoint.

If your app has already obtained access tokens for a user account, you may wish to utilize the /account/verify_credentials endpoint to check that the user remains authenticated, without directing the user to the sign-in flow.

The documentation will be updated shortly to reflect this change.

Please use the OAuth category for any related questions.

Twitter App permission not honored on subsequent oauth/authenticate calls
One-time authentication
Twitter ask for permissions on every Login
3-legged vs Twitter Sign in
Will authenticate or authorize be considered deprecated in the future?
Avoid asking user for authorization every time
Oauth/authorize endpoint no longer showing an interstitial screen for users that have authorized the app token use