Twitterでログイン
「Twitterでログイン」（または「Twitterでサインイン」）機能を使用してサイトやアプリケーション上にボタンを配置し、Twitterユーザーがわずかワンクリックで登録済みユーザーアカウントのメリットを活用できるようにしましょう。この機能は、ウェブサイト、iOS、モバイル、デスクトップアプリケーションで動作します。
機能
- 使いやすさ - サイトへの新規訪問者は、初回ログインのために2つのボタンをクリックするだけで済みます。
- Twitterとの統合 - 「Twitterでログイン」のフローにより、ユーザーに代わりTwitter APIを使用する承認を付与できます。
- OAuthベース - 豊富なクライアントライブラリとサンプルのコードは、「Twitterでログイン」のAPIと互換性があります。
対応
- ブラウザー - ユーザーがブラウザーにアクセスできれば、「Twitterでログイン」を統合できます。 ブラウザーのサインインフローをご確認ください。
- モバイル端末 - ウェブに接続されたすべてのモバイル端末で、「Twitterでログイン」のメリットを活用できます。 モバイルのサインインフローをご確認ください。
「Twitterでログイン」を実装
ブラウザーとモバイルサイトへの「Twitterでログイン」の実装はOAuthをベースにしています。このページでは、サインインフロー用のアクセストークンを取得するために必要なリクエストについて説明します。
「Twitterでログイン」フローを使用するには、Twitterアプリの設定に移動し、[Allow this app to be used to Sign in with Twitter?] オプションが有効になっていることを確認します。
このページでは、読者がOAuth 1.0aプロトコルを使用してリクエストに署名する方法を理解していることを前提としています。リクエストの署名方法を知りたい場合は、リクエストの承認ページをお読みください。
このページのリクエストの署名を確認する場合に使用されるコンシューマーシークレットは、 L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOgです。この値はテストを目的としており、実際のリクエストでは機能しません。
「Twitterでログイン」を実装する3つのステップである、リクエストトークンの取得、ユーザーのリダイレクト、リクエストトークンのアクセストークンへの変換を以下に示します。
手順1:リクエストトークンの取得
サインインフローを開始するには、署名済みメッセージをPOST oauth/request_tokenに送信してTwitterアプリがリクエストトークンを取得する必要があります。このリクエストで唯一の固有のパラメーターはoauth_callbackです。これは、手順2を完了した際にユーザーをリダイレクトする宛先となるURLのURLエンコードされたバージョンである必要があります。残りのパラメーターは、OAuth署名プロセスにより追加されます。
注 - POST oauth/request_tokenエンドポイントで使用する任意のコールバックURLは、開発者ポータルのTwitterアプリの設定内で登録する必要があります。
リクエストのサンプル（Authorizationヘッダーはラッピングされています）:
POST /oauth/request_token HTTP/1.1
User-Agent: themattharris' HTTP Client
Host: api.twitter.com
Accept: */*
Authorization:
OAuth oauth_callback="http%3A%2F%2Flocalhost%2Fsign-in-with-twitter%2F",
oauth_consumer_key="cChZNFj6T5R0TigYB9yd1w",
oauth_nonce="ea9ec8429b68d6b77cd5600adbbb0456",
oauth_signature="F1Li3tvehgcraF8DMJ7OyxO4w9Y%3D",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1318467427",
oauth_version="1.0"
アプリが応答のHTTPステータスを確認する必要があります。200以外のすべての値は失敗を示します。応答の本文には、oauth_token、oauth_token_secret、oauth_callback_confirmedパラメーターが含まれます。アプリは、oauth_callback_confirmedがtrueであることを検証し、次のステップのために他の2つの値を保存する必要があります。
応答のサンプル（応答の本文はラッピングされています）：
HTTP/1.1 200 OK
Date: Thu, 13 Oct 2011 00:57:06 GMT
Status: 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 146
Pragma: no-cache
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Vary: Accept-Encoding
Server: tfe
oauth_token=NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0&
oauth_token_secret=veNRnAWe6inFuo8o2u8SLLZLjolYDmDP7SzL0YfYI&
oauth_callback_confirmed=true
手順2:ユーザーのリダイレクト
次のステップでは、以下のブラウザーのサインインフローで説明するように、ユーザーが適切なフローを実行できるように、ユーザーをTwitterに誘導します。ユーザーをGET oauth/authenticateに誘導し、手順1で取得したリクエストトークンをoauth_tokenパラメーターとして渡す必要があります。
ウェブサイトでこれを実装する最もシームレスな方法は、元の「サインイン」リクエストへの応答として、HTTP 302リダイレクトを発行することです。モバイルとデスクトップアプリで新しいブラウザーウィンドウを開くか、内蔵ウェブビューで直接URLを開く必要があります。
リダイレクト先のURLの例：
https://api.twitter.com/oauth/authenticate?oauth_token=NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0
サインインエンドポイントは、ユーザーのステータスに応じて3つのいずれかの方法で動作します。
- サインインおよび承認済み：ユーザーがtwitter.comにサインイン済みで、すでに呼び出しアプリケーションを承認済みの場合は、ユーザーは即座に認証され、有効なOAuthリクエストトークンが付いたコールバックURLに戻されます。twitter.comへのリダイレクトはユーザーには表示されません。
- サインイン済みだが未承認：ユーザーがtwitter.comにサインインしているものの呼び出しアプリケーションを承認していない場合は、呼び出しアプリケーションとアクセスを共有するリクエストが表示されます。承認リクエストを受け入れると、ユーザーは有効なOAuthリクエストトークンが付いたコールバックURLにリダイレクトされます。
- 未サインイン：ユーザーがtwitter.comにサインインしていない場合は、認証情報を入力し、自分の情報にアクセスするアクセス権をアプリケーションに付与するように同じ画面で求められます。サインインすると、ユーザーは有効なOAuthリクエストトークンが付いたコールバックURLに戻されます。
サインインのインタラクションで可能性のある状態を、以下のフローチャートに示しています。
認証に成功すると、callback_urlはoauth_tokenとoauth_verifierパラメーターを含むリクエストを受信します。アプリケーションは、トークンが手順1で受信したリクエストトークンと一致することを検証する必要があります。
クライアントのリダイレクトからのリクエスト（クエリ文字列パラメーターはラッピングされています）：
GET /sign-in-with-twitter/?
oauth_token=NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0&
oauth_verifier=uw7NjWHT6OJ1MpJOXsHfNxoAhPKpgI8BlYDhxEjIBY HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.5 (KHTML, like Gecko) Chrome/16.0.891.1 Safari/535.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://localhost/sign-in-with-twitter/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
手順3:リクエストトークンをアクセストークンに変換
リクエストトークンを使用可能なアクセストークンにレンダリングするために、アプリケーションは、手順2で取得したoauth_verifierの値を含む、POST oauth/access_tokenエンドポイントにリクエストする必要があります。リクエストトークンはヘッダーのoauth_token部分でも引き渡されますが、これはサインインプロセスで追加されます。
リクエストのサンプル（承認ヘッダーはラッピングされています）：
POST /oauth/access_token HTTP/1.1
User-Agent: themattharris' HTTP Client
Host: api.twitter.com
Accept: */*
Authorization: OAuth oauth_consumer_key="cChZNFj6T5R0TigYB9yd1w",
oauth_nonce="a9900fe68e2573b27a37f10fbad6a755",
oauth_signature="39cipBtIOHEEnybAR4sATQTpl2I%3D",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1318467427",
oauth_token="NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0",
oauth_version="1.0"
Content-Length: 57
Content-Type: application/x-www-form-urlencoded
oauth_verifier=uw7NjWHT6OJ1MpJOXsHfNxoAhPKpgI8BlYDhxEjIBY
成功した応答には、oauth_tokenとoauth_token_secretパラメーターが含まれます。トークンとトークンシークレットは、今後認証されるTwitter APIへのリクエストに使用するために保存してください。ユーザーのIDを判断するには、GET account/verify_credentialsを使用します。
応答のサンプル（応答の本文はラッピングされています）：
HTTP/1.1 200 OK
Date: Thu, 13 Oct 2011 00:57:08 GMT
Status: 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 157
Pragma: no-cache
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Vary: Accept-Encoding
Server: tfe
oauth_token=7588892-kagSNqWge8gB1WwE3plnFsJHAZVfxWD7Vb57p0b4&
oauth_token_secret=PbKfYqSryyeKDWz4ebtY3o5ogNLG11WJuZBc9fQrQo
「Twitterでログイン」のリソース
クライアントライブラリ
Twitterライブラリでリストされているクライアントライブラリは、「Twitterでログイン」の実装に役立ちます。前の手順で説明したとおり、/oauth/authenticateエンドポイントを使用します。
ボタン
Twitterでは、一貫したブランディングのために、アプリケーションで以下のボタンを使用することを推奨します。これらの画像を保存して、ご自身のサーバーでホストしてください。
Twitterでサインイン（ボタンスタイル）：
Twitterでサインイン（リンクスタイル）：
ブラウザーのログインフローは、ウェブブラウザーを開くか内蔵できるウェブサイトとアプリケーションに適しています。概要は以下のとおりです。
- アプリケーションが「Twitterでサインイン」のリンクまたはボタンをレンダリングします。
- ユーザーがサインインボタンをクリックします。
- 現在のウェブブラウザーがTwitterにリダイレクトされます（または、新しいブラウザーが開きTwitterにリダイレクトされます）。
- ユーザーは必要に応じて「Twitterでログイン」と認証の手順を実行します。
- Twitterがアプリケーションの制御のもとでURLにリダイレクトして戻し、ユーザーに認証情報を渡します。
Twitterは認証を追跡し続けるため、すでにtwitter.comにサインインし、アプリケーションを認証したユーザーにはUIは表示されず、アプリケーションに自動的にリダイレクトされ戻されます。
デスクトップのフロー
フローを説明するために、上記のウェブサイト（「The greatest website ever created」）は、ランディングページに「Twitterでサインイン」ボタンが表示されるように、このAPIを実装したと仮定します。
ユーザーがサインインボタンをクリックして表示されるページは、サインイン済みであるかどうか、およびアプリケーションによるアカウントへのアクセスを許可済みであるかどうかによって変わります。
ユーザーがtwitter.comにサインイン済みであるもののアクセスを許可していない場合は、要求される権限のリストが、サインインとキャンセルのボタンとともに表示されます。
ユーザーがtwitter.comにサインインしていない場合は、ユーザー名とパスワードの入力フィールドが表示されます。ユーザーがすでにアプリケーションへのアクセスを許可している場合でも、権限のリストは表示されます。
ユーザーが有効な認証情報を必要に応じて入力し、[Sign In] をクリックすると、Twitterは、サインインフローが開始されたウェブサイトにユーザーをリダイレクトします。
ユーザーがtwitter.comにすでにサインイン済みでウェブサイトへのアクセスを許可している場合は、このリダイレクトは直ちに発生します。
モバイルサイトのブラウザーにおけるUIのフローはブラウザーのサインインフローとまったく同様に機能しますが、モバイルブラウザー向けに最適化されています。
以下は、サインイン済みの場合、サインアウト済みの場合、およびリダイレクトの画面のスクリーンショットです。
