概要

GoogleやTwitter認証を実装する際に出てくる「OAuth」について図解で解説していきます。

OAuth2.0の登場人物は6人

OAuth2.0の流れを理解するには、下記6つの用語について理解する必要があります。

• エンドユーザー：サービスを利用するユーザー
• Webブラウザ：Google ChromeやSafariなどのブラウザ
• クライアントアプリ：外部サービスを利用するアプリ。例えばRuby on RailsやReactなどを指します。
• 認可サービス：サービスを提供するアプリ。例えばTwitterやInstagramを指します。
• 認可エンドポイントの受付嬢：ブラウザからの認可リクエストを受け付ける場所。認可サービスのなかに存在。
• トークンエンドポイントの受付嬢：クライアントアプリからのトークンリクエストを受け付ける場所。認可サービスのなかに存在。

では、認可サービスについてもう少し詳しく見てみましょう。
例えば皆さんがRailsであるアプリを作成して、Twitterによる認証機能を付けたいとします。

Rails（クライアントアプリ）は、各ユーザーのTwitter情報（ID名やアカウント名）など自力で入手することができません。
そのため、情報を持っているTwitterから情報を入手する必要があります。

このようにクライアントアプリに情報を与える外部のサービスを、認可サービスと呼びます。
今回は分かりやすく、認可サービスとリソースサービスを同じと考えます。

さて話を戻します。
エンドユーザーがあるサービスを見つけた場合を想像してください。


最近のアプリケーションなら、メールアドレス以外にGoogleやTwitterアカウントでログインできるようになっていますよね。さて、ユーザーがTwitterでログインをクリックしたとしましょう。

Webブラウザが認可リクエスト画面を表示

ユーザーがボタンをクリックすると、クライアントアプリがWebブラウザに「認可リクエスト」を表示するように命令します。



これによりWebブラウザで表示されるのが、「認可リクエスト画面」です。

例えばTwitterアカウントでログインすると、下画像のようにユーザーに許可を求める画面が表示されますよね。


ちなみに認可リクエスト（認可リクエスト画面表示時のURL）は下記のようになっています。
Twitterでのログインをする際に、URLをチェックしてみるとイメージがわくと思います。

Webブラウザが認可レスポンスを入手

次にユーザーが認可を許可したとします。
そうするとWebブラウザは認可サーバーに、「認可レスポンス」を求めます。

認可レスポンスの受付は、認可サーバーの「認可エンドポイント」で行います。
この認可エンドポイントにアクセスすることで、Webブラウザが認可レスポンスを受け取ることができるわけです。


さてWebブラウザが、認可サーバーから「認可レスポンス」を受け取ったら、それをクライアントアプリに渡します。

クライアントアプリトークンリクエストを投げる

認可レスポンスを受け取ったクライアントは、それをもとに認可サーバーにリクエストを投げます。その場合の受付は、「トークンエンドポイント」となります。

クライアントは、認可レスポンスと引き換えに、アクセストークンを手に入れます。



そしてトークンエンドポイントに下記の情報を含んだリクエストを投げます。



トークンエンドポイントから、クライアントは下記のような情報を入手します。
レスポンスの形式がJSONの場合、下記のような形になります。



このアクセストークンをもとに外部サーバーにアクセスできます。



これでようやく外部サービスを利用できるようになったわけです。



長かったですね...