/authenticate vs /authorize (or force_login vs direct messages ?)



I’m currently using /oauth/authenticate for the authorization step because of the force_login parameter. I need the force_login parameter because I want users to double-check which account they are authorizing.

I now need the direct messages permission; it seems to work when authorizing on /authorize, but not on /authenticate.

Is there any way to have both force_login and direct message permissions ?



On /authenticate I see

This application will not be able to:
Access your direct messages.
See your Twitter password.

On /authorize I see only:

This application will not be able to:
See your Twitter password.


Hi Arnaud,

At the time of the DM permission change, we actually added force_login support to the /authorize flow as well, so you can just swap to using /authorize for the behaviour support you want.

The remaining difference between /authenticate and /authorize is that sans-force_login, /authenticate allows you to auto-redirect a user who has already authed your app, whereas /authorize requires user interaction (as per the standard OAuth design, whereas /authenticate deviates from it.)

FWIW, whilst only /authorize can be used to initially grant a DM-capable access token, you can use /authorize for the first time a user auths, and then use /authenticate on subsequent auths to auto-redirect if that’s what you want: A token that already exists with DM permissions will not be altered by /authenticate.


Hi Ben,

Thanks for your answer, that’s perfectly clear.

Right now I’m seeing the force-login form on /authorize, but from time to time I don’t see it. I guess this is related with some cache and that it’s a matter of time.



So is there any reason to ever use /authenticate ?


The reason I’d use /authenticate is for signing in a user with Twitter. /authorize asks access confirmation from the user every time, while /authenticate doesn’t - one step less for the user.


Hi Ben,

I have found that using /authenticate alters a DM-capable token (created using /authorize) and replaces it with a RW-only token. Steps to reproduce:

  1. Use /authorize to generate DM-capable token.
  2. Sign out of Twitter.
  3. Use /authenticate to sign the user in.

After these, I find that the DM-capable token has been replaced by a RW-only token. What’s happening here?