Application Permission Model FAQ

Table of Contents

If you have another question which isn’t answered let us know on the Developer Mailing List.

Two weeks is not enough time to implement a web OAuth flow and have the app approved. We need an extension.

We’ve heard your feedback on this list, privately and through Tweets about this. Based on this feedback we are going to extend the enforcement deadline.

This means we’ll enforce the new permission on the 30th June 2011. This should provide enough time for you to make the change and have your application approved by your chosen platform’s app store.

Will Twitter’s own applications also go through the OAuth web flow?

We’re taking this step to give more clarity and control to users about the access a third-party application has to their account. The way users interact with Twitter’s clients is not expected to change. Applications who wish to access a user’s DMs will need to update their application permission and incorporate the OAuth web flow if they don’t already. If an application does not need access to DMs it will not need to make any changes.

Why will you not grandfather existing applications into DM access?

Grandfathering all existing read/write tokens assumes they all wanted access to DMs. The feedback we’ve had from users and developers tells us otherwise. We want to give users the opportunity to make an informed choice.

What if the client using xAuth has no browser and therefore cannot go through OAuth?

For single user applications and scripts we provide the ‘My Access Token’ page of the application details. To ensure the ‘My Access Token’ is correct it is important the app owner revokes their access before change the permission level of the app. If you do not do this, the ‘My Access Token’ will not be regenerated with the new permission. This revoke action is only needed by you, the owner of the application. Remember Read/Write applications can still send direct messages.

When you activate the new permission, will all Read and Read/Write user_tokens issued to third-party applications lose their ability to read direct messages?

Existing tokens are unaffected by any change to the application permission level. If you change your application to R/W/DM all future authorizations will be for that permission. When a user re-authorizes, their existing token will be updated to the current application permission level. Access to DMs will be enforced on 14th June 2011 if the user_token wasn’t authorised as for R/W/DM.

What if I want to request a different level of access for my application instead of the one my application is registered with?

You can do this now by using the x_auth_access_type parameter during the request_token phase. Using this parameter you can request a read or a read/write token even if your application is registered for read/ write/direct messages.

More information on this method is in our developer documentation: /oauth/reference/post/oauth/request_token

Why are permissions attached to the user token?

Permissions are attached to the user token to ensure an application only has the access a user has authorised. If permissions were not attached to the user token an application would be able to change the level of access they have without the user’s knowledge. If you tie the permissions to the application each user token would need to be invalidated whenever an application’s permissions are changed.

Users already gave their permission for apps to access direct messages, why are you making us, and them, reauthorize?

The purpose of the re-authorization is to ensure both users and developers know the level of access requested. Re-authorization allows a user to make a more informed decision about the access an application has requested.

We hope these responses answer your questions. Please continue to send us your feedback about the permission model and what you would like to see it offer.

Can Read/Write applications send direct messages?

Yes. Read/Write tokens can send direct messages using direct_messages/new.

The endpoints which will require the R/W/DM permission will be:

  • /1/direct_messages.{format}
  • /1/direct_messages/sent.{format}
  • /1/direct_messages/destroy.{format}
  • /1/direct_messages/show.{format}

I adjusted my application permissions but the OAuth login still shows no permissions for direct messages. Should this change have been immediate?

The permission level for your application can be edited on /apps. When the website is busy, it can take a little bit longer for changes to your application to be reflected.

Is using a web view against the Terms of Service (TOS)?

Using an in-app web view to show the OAuth pages is not against our TOS. However, we encourage developers to use the built-in browser where appropriate.

You said you were restricting this permission to the OAuth /authorize web flow only. Will /oauth/authenticate (Sign in with Twitter) support the new permission?

The R/W/DM permission can only be granted through the /oauth/authorize route. Sign in with Twitter cannot be used to grant R/W/DM.

We understand applications may use other methods of authentication like Sign in with Twitter as well. For this reason, if a user has authorised your application for R/W/DM and you direct them through Sign in with Twitter, we will respect the existing access token permission. This means you can use Sign in with Twitter after a user has authorized your application for R/W/DM.

I’ve read that users will be asked to do this on every use of an application, is that true?

No, this is a misunderstanding. The way OAuth works hasn’t changed and users only need to authorize an application once. Remember we do not expire access tokens and the only time users have to reauthorize is when an application requests them to.

Wouldn’t it be possible to keep the DM access rights with xAuth and only revoke it upon user complaints or your monitoring of API usage?

The reason for asking users to reauthorize is so they can make a more informed decision about the access an application has requested.

There may be users of your application who are comfortable with the level of access you have requested, while there could be others who complain. By having the user re-authorize, they get to decide if they agree with the access your application has requested.

The way it’s being taken in the news is that Twitter is doing this because developers have been abusing their privacy.

The new permission level has been added in response to user and developer requests for more clarity around the access an application has to an account.

I have not seen a method we can use to effectively test this besides changing our code and waiting?

When the new permission is enforced we will return an HTTP 403 Forbidden error with the response body:

{"errors":[{"code":93,"message":"This application is not allowed to access or delete your direct messages"}]}

How do we know what the access level of a user token is?

For all authenticated API requests, we’re returning the “X-Access-Level” header that tells you what access level the user token you’re using has:

  • “read” (Read-only)
  • “read-write” (Read & Write)
  • “read-write-directmessages” (Read, Write, & Direct Message)

We support multiple accounts in our application, how do we force a login on the authorize flow?

Currently the only flow that supports the force_login parameter is /oauth/authenticate but adding it to /oauth/authorize flow is a good idea. We’ll begin working on this now and will let you know when it is released.

Is there sample code we can use that shows the appropriate OAuth flow and how to handle multiple users?

This is a great idea and one which is best handled by our client teams. When they have some example code we’ll let you know.

How do I specify a custom callback URL? The website won’t let me.

You can set the callback dynamically during the request_token phase of OAuth. To this you should register your application as browser based, and put a placeholder URL in the callback box. The placeholder URL should be something like the about page of your application. Custom callbacks can only be specified at runtime and cannot be registered as the default callback of an application.

More information on the request_token method is provided on our developer resources site: /oauth/reference/post/oauth/request_token

Be sure to include a path with your callback. For example: myapp://oauth_complete

Can I use the Read & Write with Direct Messages permission in native iOS5 integrations?

You will need to negotiate an access token using the web-based OAuth flow to access direct messages in native iOS5 integrations using TWRequest.