「OAuth」の基本動作を知る：デジタル・アイデンティティ技術最新動向（1）（2/2 ページ）

» 2017年09月01日 05時00分公開

OAuthの登場人物

　OAuthは3つの登場人物（要素）で構成されています（図1）。

図1　OAuthの登場人物

　先ほどの例のFacebookやTwitterなどのように、OAuthをサポートしたAPIを提供しているサービスを「OAuth Server」と呼びます。また、それらのAPIを利用するInstagramやFoursquare、Pinterestなど、OAuth Serverが提供するAPIを利用する側のサービスは「OAuth Client」と呼ばれます。そして、アクセス権限の付与を行うユーザー自身は「Resource Owner」と呼ばれます（注2）。

注2：OAuth 1.0が出てきたころは、OAuth Serverのことを「OAuth Service Provider」、OAuth Clientのことを「OAuth Consumer」と呼んでいました。その名残で、いまでもそのように呼ばれているケースもあります。

　最近ではほとんどのAPIで何らかのアクセスコントロールが必要になっており、よほどの理由がない限り、その部分ではOAuthを選択することになるでしょう。ですから、

APIを外部公開しているサービスはOAuth Serverになり
外部プラットフォームが提供するAPIを利用するサービスはOAuth Clientになり
その両方のケースが混在する場合にはOAuth ServerにもなりOAuth Clientにもなる

といってしまってもいいかもしれません。もちろん、自分がOAuth Client側にいる場合は、各プラットフォームに特化したライブラリを利用するなどして直接OAuthに触れない場合もあるかもしれませんが。

OAuthの基本的な流れ

　続いて、OAuthではどういった処理が行われるかを見ていきましょう（図2）。

図2　処理のフロー

■Step 0：Client Registration（クライアント登録）

　OAuth Clientは、ユーザーとのインタラクションを行う前に、OAuth Serverに対してアプリ名やドメインなどを添えて自身を登録します。クライアント登録の方法についてはOAuthの仕様では定められていませんが、通常はAPI提供者のデベロッパー向けサイトなどでアプリケーションを登録することになるでしょう。一度クライアント登録が完了すれば、このステップは次回以降は必要ありません。

画面4　Facebookであればdevelopers.facebook.comでアプリケーション登録を行う

■Step 1：Initiate（フロー開始）

　OAuthではまず、OAuth ClientがResource OwnerからAPIアクセス権限の付与を受ける必要があります。OAuth 1.0とOAuth 2.0とで多少このフローは異なりますが、基本的にはOAuth Client上に「Facebook IDでログイン」などのリンクもしくはボタンがあり、ユーザーがそれをクリックすることでフローが開始されます。

画面5　Pinterestのログイン画面

■Step 2：Authorization Request（認可のリクエスト）

　フローが開始されると、OAuth ClientはユーザーをOAuth Serverにリダイレクトさせます。この際、ServerがどのClientからリダイレクトを受けたか判断できるように、OAuth Clientの識別情報を付与します。具体的にどのようなClient識別情報が付与されるかは、OAuth 1.0とOAuth 2.0で異なりますが、OAuth 2.0では「client_id」というパラメータがそれに該当します。

■Step 3：Authenticate User & Get Approval（ユーザー認証とアクセス権限付与）

　リダイレクトを受けたOAuth Serverは、ユーザーを認証し、その後ユーザーに対して該当Clientへのアクセス権限付与を許可するかどうかを尋ねます。この際のユーザー認証方法は、OAuthの仕様には含まれません。通常は、IDとパスワードの組み合わせを使ったり、Session Cookieなどを用いて認証を行うことになるでしょう。

画面6　Facebookのアクセス権限付与同意画面

■Step 4：Authorization Response（認可レスポンス）

　ユーザーがアクセス権限の付与を許可すると、OAuth ServerはユーザーをOAuth Clientにリダイレクトして戻します。この際、リダイレクトURLには、アクセス権限付与を示すトークンが含まれます。

　このトークンの表現形式もOAuth 1.0とOAuth 2.0で異なり、OAuth 2.0ではClientの特性（WebアプリなのかNativeアプリなのか等々）によって、「code」と「access_token」という2種類のトークン形式が存在します。OAuth 2.0の仕様では、アクセス権限の付与を示す情報を「Grant」と呼びます。

■Step 5：Obtain Access Token（アクセストークンとの交換）

　OAuth Clientは最後に、受け取ったトークンをAccess Token（アクセストークン）と交換します。Access Tokenは、後にAPIアクセスを行う際に、アクセス権限付与を受けていることを証明するために用いられるトークンです。Step 4ですでにaccess_tokenというパラメータを受け取っている場合は、それがAccess Tokenに相当するため、このステップはスキップされます。

■Step 6：API Access（APIへのアクセス）

　ひとたびAccess Tokenを受け取ると、それが期限切れになるか、あるいは無効化されるまでは、（基本的には何度でも）それを使ってAPIにアクセスできます。

第2回に向けて

　今回は、OAuthの概要を説明するだけで終わってしまいました。次回は引き続きOAuthについて、

OAuth 1.0とOAuth 2.0の違い
OAuth 2.0をセキュアに使うために知っておくべきこと

という観点から述べていきます。

　また、この連載では紹介しきれない仕様全体について詳しく知りたい場合は、OpenID Foundation Japanが翻訳したOAuth仕様の日本語版（OAuth 1.0、OAuth 2.0 Core & OAuth 2.0 Bearer Tokenの日本語版仕様など）を一読することもお勧めします。