-Twitter offers a few different methods of integration. What we are using here is the "3-legged authorization" method as described [here](https://dev.twitter.com/docs/auth/3-legged-authorization). Behind the scenes, we are using OAuth 1.0a to talk to Twitter. You can get the gory details about how Twitter uses OAuth [here](https://dev.twitter.com/docs/auth/oauth).

+Twitter offers a few different methods of integration. This strategy implements the browser variant of the "[Sign in with Twitter](https://dev.twitter.com/docs/auth/implementing-sign-twitter)" flow.

-##Before you begin

+Twitter uses OAuth 1.0a. Twitter's developer area contains ample documentation on how it implements this, so if you are really interested in the details, go check that out for more.

-If you have not already done so, sign in into the [Twitter developer area](http://dev.twitter.com) and create an application. Take note of your Consumer Key and Consumer Secret (not the Access Token and Secret) because that is what your web application will use to authenticate against the Twitter API.

+##Before You Begin

-Also, we assume you've already installed OmniAuth in your app; if not, read the [OmniAuth README](https://github.com/intridea/omniauth) to get started.

+You should have already installed OmniAuth into your app; if not, read the [OmniAuth README](https://github.com/intridea/omniauth) to get started.

-##Using this Strategy

+Now sign in into the [Twitter developer area](http://dev.twitter.com) and create an application. Take note of your Consumer Key and Consumer Secret (not the Access Token and Secret) because that is what your web application will use to authenticate against the Twitter API. Make sure to set a callback URL or else you may get authentication errors. (It doesn't matter what it is, just that it is set.)

-Twitter supports a [few options](https://dev.twitter.com/docs/api/1/get/oauth/authenticate) when authenticating. Usually you would specify these options as query parameters to the Twitter API authentication url (https://api.twitter.com/oauth/authenticate by default). With OmniAuth, of course, you use `http://yourapp.com/auth/twitter` instead. Because of this, this OmniAuth provider will pick up the query parameters you pass to the `/auth/twitter` URL and re-use them when making the call to the Twitter API.

+Twitter supports a [few options](https://dev.twitter.com/docs/api/1/get/oauth/authenticate) when authenticating. Usually you would specify these options as query parameters to the Twitter API authentication url (`https://api.twitter.com/oauth/authenticate` by default). With OmniAuth, of course, you use `http://yourapp.com/auth/twitter` instead. Because of this, this OmniAuth provider will pick up the query parameters you pass to the `/auth/twitter` URL and re-use them when making the call to the Twitter API.

The options are:

@@ -40,6 +42,8 @@ The options are:

***x_auth_access_type** - This option (described [here](https://dev.twitter.com/docs/api/1/post/oauth/request_token)) lets you request the level of access that your app will have to the Twitter account in question. *Example:*`http://yoursite.com/auth/twitter?x_auth_access_type=read`

+***use_authorize** - There are actually two URLs you can use against the Twitter API. As mentioned, the default is `https://api.twitter.com/oauth/authenticate`, but you also have `https://api.twitter.com/oauth/authorize`. Passing this option as `true` will use the second URL rather than the first. What's the difference? As described [here](https://dev.twitter.com/docs/api/1/get/oauth/authenticate), with `authenticate`, if your user has already granted permission to your application, Twitter will redirect straight back to your application, whereas `authorize` forces the user to go through the "grant permission" screen again. For certain use cases this may be necessary. *Example:*`http://yoursite.com/auth/twitter?use_authorize=true`