OAuth2.0のざっくりしたまとめ

Webアプリケーションを作ったり使ったりする上で認証・認可の仕組みはほぼ必須の要素になっていると思います。

その中でも今回はOAuthについてまとめてみます。

そもそも認証・認可とは

混同しがちですが、認証と認可は異なります。

認証(Authentication)は相手が誰であるかを判別することであり、認可(Authorization)はリソースにアクセスする権限を与えることを指します。

例えば、最近だと指紋認証や顔認証といった生体認証は個人を特定することが目的なので「認証」です。「指紋認可」とは言いません。

一方で鍵を持っていることでロックされた部屋に入ることができたり、免許証を持っていることで車を運転できたりします。これは認可に当たります。

この場合、鍵を持っているのが誰であるかは問われません。もしかしたら盗んだ鍵かもしれませんが、それを持っていることで部屋を開ける権限が得られたと言えます。

Webにおける認証・認可

認証と認可は密接に結びついていることが多いです。

通常、Webアプリケーションではアカウントを作成してログインするとそのアプリケーション内で色々操作できるようになります。

例えばTwitterで言うと未ログイン時はタイムラインやツイートを見ることしかできないですが、ログインすると自分でもツイートできたり、いいねできたり、リストを作れたりします。

これはアカウントを作成してログインする(認証)ことでツイートやいいねすることができる(認可)ようになると言えます。

一方で複数のサービスに1つのアカウントでログインできたら便利だな、と思います。

それを実現するのがOAuthです。

OAuthとは

OAuthは認可の仕組みを提供するプロトコルです。認証ではありません。

An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.

OAuth Community Site

複数のサービスを連携させることができ、別のサービスを利用する為のトークンを発行することができます。

例えばまたTwitterを例に出すと、質問箱等のサービスを利用する時にこんな画面を見たことはありませんか。

引用元: https://developer.twitter.com/ja/docs/authentication/oauth-1-0a/obtaining-user-access-tokens

これもOAuthを使った仕組みです。

他にもGoogleアカウントやFacebookアカウント等でサインアップできるサービスは数多くあります。あれも同様にOAuthを使った認可の仕組みです。

以降、現在の標準規格であるOAuth2.0について説明します。

OAuth2.0の仕組み

OAuth2.0には登場人物が4人出てきます。

  • リソースオーナー(エンドユーザー)
  • リソースサーバー
  • 認可サーバー
  • クライアント

リソースオーナーは保護すべきリソースの所有者です。個人の場合はエンドユーザーとも言います。

リソースサーバーは保護すべきリソースを保存しているサーバーのことです。先の例で言うとTwitterに当たります。

認可サーバーはリソースオーナーの認証を行い、リソースサーバーへのアクセスを認可する役割を担います。

クライアントはリソースサーバーにアクセスしたいアプリケーション等を指します。先の例で言うと質問箱等に当たります。

では順番に見ていきます。

クライアントから認可サーバーへのリダイレクト

エンドユーザーが「Twitterでログイン」ボタンを押すと必要なパラメータを付加した上で認可サーバーへリダイレクトします。

この時に付くパラメータで連携後にリダイレクトする先のURLやどのリソースにアクセスできる権限を取得するか(=スコープ)等を指定します。

認可サーバーからエンドユーザーに認可リクエストを送信

認可サーバーはエンドユーザーに対してリソースの使用可否を求めるリクエストを送信します。

先程のTwitterの画面がそれです。

エンドユーザーが認可サーバーに対して許可

スコープ等を確認した上でエンドユーザーがアクセスを許可します。

認可サーバーがクライアントに対して認可コードを発行

エンドユーザーが許可すると認可サーバーは一時的な認可コードを発行し、クライアントに送信します。

クライアントが認可サーバーに対してアクセストークンをリクエス

クライアントは先程の認可コードを元に認可サーバーのトークンエンドポイントに対してアクセストークンの発行をリクエストします。

認可コードが正しければ認可コードはアクセストークンを発行します。

以上がOAuth2.0の大まかな流れです。

以降はアクセストークンを元にリソースサーバーのAPIを叩くことなどが可能になります。

まとめ

以上、OAuth2.0について簡単にまとめてみました。

細かい仕様についてはRFCで定められているのでそちらもそのうちまとめたいと思います。