OAuth2の解説サイトを漁る前に

  • 9
    いいね
  • 0
    コメント

Twitter、Facebook、Githubなどのアカウントを使用して別のサービスにサインアップできるの、超便利ですよね。
でも実装したいと思ってOAuth2の概要図をGoogle画像検索してみても、どうも頭の中と登場する単語や図が一致しない、という人もきっといると思います。(いますよね?)

私のように今更ながらOAuth2のことを理解しようとしている方のために、
様々なOAuth2解説を読む前に抑えておくべきポイントを記載します。

OAuth2をしっかり理解されている方へ

この記事では、細かい正確な仕組みを省いています。登場人物や世界観を大まかに把握するための記事ですので、細かいネタバレを含みません。
また、登場する単語は極力広く認識されている単語を使用しますが、間違いがあればご指摘ください。

というわけで、みなさまのお役に立てば幸いです。

OAuth2は「認証(Authentication)」の仕組みではなく「認可(Authorization)」の仕組み

OAuth2は「ユーザ/パスワードで本人確認」する仕組みではありません。
正しくは「特定のデータへ特定の操作を許可」する仕組みです。

例えばGithubアカウントを使用したOAuth2であれば、「リポジトリ一覧を読み取り専用でアクセスしてOKです。リポジトリの追加はできません。」を達成することが目的です。
この達成目標のために、結果的に認証も行うため、認証の仕組みとしても広く利用されているというだけです。

OAuth2の解説はOAuth2を「利用したいアプリケーションからの目線」で記載されている(ことがほとんど)

OAuth2を理解するにあたって、重要なアクターは次の3つです(他にもいくつか中間のアクターがあります)。

  • リソースサーバ(取得したいデータのあるサーバ)
  • クライアント(データを取得して利用したいアプリケーション)
  • エンドユーザ(取得したいデータの所有者)

例えば、QiitaはGithubアカウントを使用したOAuth2で認証可能です。
上記3つのアクターに当てはめると次の通りです。

  • リソースサーバ:Githubサーバ
  • クライアント:Qiitaアプリケーション
  • エンドユーザ:Qiitaアプリケーションにアクセスしているあなた

OAuth2の仕組み大まか概要図

最後に、かなり大まかにOAuth2を図解してみます。
以下の文章も、クライアント視点で記述しています。

運用開始前

アプリを実装する段階で、事前準備をしておく必要があります。

OAuth2(準備).png

(0) 事前にリソースサーバから「クライアントID」をもらっておくことが必要です(ここで「ユーザ情報を読み取るだけ」などの権限を指定します)。

認証~認可処理

実際に認証~認可処理を行います。

OAuth2.png

※1 本来はリソースサーバ(ユーザ情報など、取得したい情報を持っているサーバ)と認可サーバ(トークンを管理するサーバ)は独立して考えますが、ここでは同一サーバで実現する想定で記載します。

(1) エンドユーザがアクセスしてきましたが、まずはリソースサーバで先に認証を行ってもらいます。
(2) エンドユーザはID/パスワードをリソースサーバに渡して、「認可コード(リソースサーバから認可が下りたことを示すコード)」を得ます。これが、エンドユーザがID/パスワードを入力する一度きりの機会です。
(3) 「認可コード」をクライアントに預けます。
(4) クライアントは自分を示す「クライアントID」と、エンドユーザから預かった「認可コード」をリソースサーバに示します。これでクライアントは”エンドユーザの代わりに、エンドユーザが所有するリソースに対して限られた操作ができる権利”として「アクセストークン」を得ます。

認可後

OAuth2(認可完了後) (1).png

ついにクライアントは「アクセストークン」を示すことで、ほしいリソースに繰り返しアクセスすることができるようになります。
※アクセストークンには基本的に有効期限がつきます

おわりに

とりあえずこの記事を読み終わった段階で、みなさんのアプリケーションにおいてOAuth2を検討するか否かが判断きるようなものになっていれば幸いです。