Warning: count(): Parameter must be an array or an object that implements Countable in /home/xs638785/agile-software.site/public_html/wp-content/plugins/rich-table-of-content/functions.php on line 490
インターネット上でYouTubeやFacebookなどのSNS（ソーシャル・ネットワーク・サービス）、ユーザー登録をして利用するWebサービスが増えてきました。これら複数のサービスを利用する時に、わざわざIDとパスワードを入れ直したりせずに、シームレスに利用できるようにする仕組みが「OAuth」です。
ID・パスワード認証とOAuth
ID・パスワード認証
従来のIDとパスワードによる認証です。GoogleやOffice365等の外部サービスのAPIの呼び出しに長いこと使われてきました。
- FacebookのシステムにAさんのTwitterパスワードを登録します。
- Aさんが投稿します。
- Facebookのシステムに登録されているTwitterのユーザーID・パスワードを元にTwitterに接続します。
- FacebookがユーザーAさんの代わりにTwitterに投稿します。
このしくみは、大きな弱点があります。FacebookにはAさんのTwitterのユーザーID・パスワードが登録されています。Facebookを運営している人に悪い人がいて、その人がAさんのTwitterのID・パスワードで勝手にTwitterに接続できてしまいます。投稿の削除やアカウントの削除ができてしまいます。これを解決するのはOAuthです。OAuthは、Facebook側にTwitterのユーザーID・パスワードを登録することなく、Twitterにアクセスします。
OAuth
1. サービスプロバイダーが、コンシューマーにOAuth利用許可を与える
この操作は、ユーザーがリクエストを行う前に、Facebookを運営するシステム管理者は、Twitterに対して、Oauthで接続させてくださいみたいな事前の申請をします。具体的には、コンシューマーがサービスプロバイダーに登録を行い、「登録証明書」にあたるConsumer KeyとConsumer Secretという値を取得します。つまり、
2. ユーザーの同意を確認する
申請が終わると、Twitterは「クライアントID」「クライアントシークレット」をFacebookシステム管理者に発行します。
Facebook、Twitterは、そのクライアントID、クライアントシークレット、利用サービスを自身のデータベースに保存します。
3.API経由の許可を与える
ここからは、利用者であるAさんがFacebook→Twitter連携を行います。まず、Aさんは、Facebookにアクセスして、Facebook→Twitter連携の設定画面にアクセスします。
4.API経
すると、Aさんは、Twitterにリダイレクトされて、Twitterのログイン画面が表示されます。このリダイレクトの際、URLのクエリパラメータにclient_idを付与します。次の工程でこれを使います。
5.API経
ログインすると、Twitterは、Facebookと連携してもよいかどうかの確認画面を表示します。Twitterは、多分、いろんなサービスとの連携を許可していると思いますが、その多数あるサービスの中から、Facebookとの連携がOKかどうかの画面を表示できたのは、先程リダイレクトの際にクエリパラメータに渡されたクライアントIDから判断しています。
6.API経
Aさんが先程の画面で「OK」をクリックすると、Facebookにリダイレクトされます。この際、認可コードというものが発行されます。リダイレクトされたときのURLのクエリパラメータにcode=…と言うかたちで、Facebookに渡されます。これは、後にFacebookがTwitterにアクセストークンを要求するための、非常に有効期限の短い通行手形のようなものです。Facebookは認可コード発行と同時に、認可コードを自身のデータベースに保存します。
7.API経
FacebookはTwitterにアクセストークンを取得しに行きます。その際、先程発行された認可コードを渡します。
8.API経
要求されたTwitterは、自身が発行してデータベースに登録した認可コードとその有効期限を確認し、問題がなければ、Facebookにアクセストークンを返します。アクセストークンを発行したTwitter、アクセストークンを受け取ったFacebookの両方は、ユーザーIDとアクセストークンが紐付いた情報をデータベースに登録します。
9.API経
Aさんは、Facebookに投稿します。
FacebookはAさんの投稿を画面に表示します。それと同時に、Twitterにも同様の投稿を行います。この際、Twitterには、投稿の内容と同時に、アクセストークンを渡します。アクセストークンは、Twitterへのログインユーザーをキーにデータベースから取得します。
10.API経
アクセストークンを受け取ったTwitterは、データベースからアクセストークンを検索して、もし見つかったら、それに紐づくユーザーIDで、Twitterに投稿します。これで、連携完了です。
これがOAuthの最大のメリットです。ID・パスワード認証をそのまま他のサービスに渡すと、どのように使われるかわかりません。OAuthのトークンであれば、被害を最小限に済ませることができます。
概念
（２）ユーザーのデータを管理するサーバーがあります。これを『リソースサーバー』と呼びます。
（３）ユーザーのデータを利用したい『クライアントアプリケーション』があります。
（４）ユーザーのデータをやりとりする口を用意します。これを『API（エーピーアイ）』と呼びます。
（５）クライアントアプリケーションがユーザーのデータをリソースサーバーに要求します。
（６）リソースサーバーはクライアントアプリケーションにユーザーのデータを渡します。
（８）ユーザーのデータを要求しているのが悪意のあるアプリだとしても、
（９）リソースサーバーはユーザーのデータを渡してしまいます。
（１０）このままでは、悪意のあるアプリにもユーザーのデータが渡ってしまいます。
（１２）API を守る仕組みのベストプラクティスでは、あらかじめクライアントアプリケーションに『アクセストークン』というものを持たせておきます。アクセストークンは、当該クライアントアプリケーションがユーザーのデータを利用することを許可されていることを示すものです。
（１３）クライアントアプリケーションは、ユーザーのデータを要求する際、アクセストークンを提示します。
（１４）リソースサーバーは、リクエストに含まれているアクセストークンを取り出し、
（１５）ユーザーのデータを利用する権限があるかどうかを調べます。
（１６）必要な権限があることを確認したあとに、ユーザーのデータをクライアントアプリケーションに渡します。
（１７）この仕組みを機能させるためには、あらかじめクライアントアプリケーションにアクセストークンを渡しておく必要があります。
（１８）必然の帰結として、アクセストークンを発行する係が必要となります。
（２１）認可サーバーとクライアントアプリケーションの関係を簡単に説明します。
（２３）クライアントアプリケーションに対してアクセストークンを発行します。
（２４）ここまでの内容を復習します。登場人物は、認可サーバー、クライアントアプリケーション、リソースサーバーです。
注：認可サーバーの役割とリソースサーバーの役割を一つのサーバーが兼ねることもよくあります。
（２７）クライアントアプリケーションは、アクセストークンを添えて、リソースサーバーにユーザーのデータを要求します。
（２８）リソースサーバーはリクエストからアクセストークンを取り出し、
（２９）アクセストークンがユーザーのデータを利用する権限を持っていることを確認し、
（３０）ユーザーのデータをクライアントアプリケーションに渡します。
（３１）ここまでは、認可サーバーがいきなりアクセストークンを生成してクライアントアプリケーションに発行するという流れでしたが、実際は、アクセストークンを発行する前にユーザーに確認を取ります。
（３２）まず、クライアントアプリケーションが認可サーバーに対してアクセストークンを要求します。
（３３）すると、認可サーバーは、クライアントアプリケーションが要求している権限を与えるかどうかをユーザーに確認します。
（３４）ユーザーがクライアントアプリケーションに権限を与えることを了承すれば、
（３６）クライアントアプリケーションにアクセストークンを発行します。
（３８）これは、アクセストークンの要求とその応答を表しています。
（３９）そして、この部分を標準化したものが『OAuth 2.0』です。OAuth 2.0 の詳細は、技術文書 RFC 6749 で定義されています。
