OAuth2の概要を分かりやすく説明

はじめに

OAuth2とは、HTTP通信を用いた認証のフレームワークで、Webサイトやモバイルアプリなどのアプリケーションにパスワードを共有せずともアカウントへの限定的なアクセス権限を付与できる仕組みです。
FacebookログインやGoogleログインなどもOAuth2を用いてます。例えばFacebookログインを用いてGithubにログインする場合、FacebookはOAuthによってGithubにユーザープロフィールへのアクセス権限を付与します。GithubはFacebookからユーザーのパスワードを共有されないのであなたのアカウントを乗っ取る事はできません。また権限は限定的なので、Githubはメールアドレスなどの一部の情報にしかアクセスできません。
このようにOAuth2を用いると必要な情報のみを安全に公開することが出来るようになります。

この記事ではOAuth2の概要について説明します。

OAuth ロール

OAuthでは4つのロールがあります。
– リソースオーナー
– クライアント
– リソースサーバー
– 認証サーバー

以下、それぞれについて詳細を説明します。

リソースオーナー: ユーザー

リソースオーナーとは、アプリケーションにアカウントへのアクセス権限を付与するユーザーを示します。アプリケーションのアクセス権限は許可された権限の範囲に限定されます。

リソース / 認証サーバー: サービス

リソースサーバーはユーザーアカウントを所持しているサーバーで、ユーザーを認証してアプリケーションに*アクセストークン*を付与します。
アプリケーションからすると、サーバーはリソースの提供と認証サーバーの両方の役割を提供します。この両者の役割を合わせてサービスと読みます。

クライアント: アプリケーション

クライアントは、ユーザー情報にアクセスしたいアプリケーションのことです。アプリケーションがユーザー情報にアクセスするためには、ユーザーによってアプリケーションが認証され、サービスによって認証される必要があります。

OAuthプロトコルの認証フロー

先ほどのロールの概念を踏まえ、次の図で認証フローを追ってみましょう。

 

OAuth2protocol

  1.  アプリケーションはリソースにアクセスするための認証許可をユーザーに求めます。
  2. ユーザーが許可をすると、アプリケーションは認証許可を得ます。
  3.  アプリケーションはユーザーIDとユーザーからの認証許可を得た印を認証サーバーに送り、アクセストークンをリクエストします。
  4.  認証サーバーは認証許可が有効なもので、アプリケーションのアイデンティティが認証されればアプリケーションにアクセストークンを発行します。
  5.  アプリケーションはリソースサーバーにアクセストークンと共にリソースへをリクエストします。
  6.  リソースサーバーはアクセストークンが有効なものであればリソースをアプリケーションに返します。

実際のフローは認証タイプによって異なりますが、一般的な概念は上記のようなフローになっています。

 

終わりに

Firebaseを用いたFacebook認証など、Auth2の仕組みを利用した認証の利用シーが増えています。しかし、0Authの概要を理解していないために設定で詰まった時にどこが問題か分からずに詰まるケースが多いです。前提となる仕組みの概要を理解しておくのがOAuthを利用したツールの習得への近道なので、しっかりOAuthを理解しておきましょう。