Web API: The Good Partsを読んだので「OAuthの仕組み」についてまとめた #API

はじめに

APIの勉強のために、Web API: The Good Partsを読みました。平易な日本語で書いてあるので、読みやすかったです。
とはいえ、何度も本を読み返すのは大変なので、自分用まとめも兼ねて書こうと思った次第です。

1個1個まとめていくと結構な量があるので今回は「OAuthの仕組み」についてまとめました。本の内容だけだと少し足りなかったので適宜ネットからの情報も参考にしています。
本でいうと2.6章に書いてあります。

この記事も参考に

Web API: The Good Partsの他のまとめ記事もここに載せておきます。

OAuthとは

OAuthとは、「認可情報の移譲」のための仕様のこと。
ざっくりいうと以下のとおり。

①あらかじめ信頼関係を構築したサービス間で、②ユーザーの同意のもとに、③セキュアにユーザーの権限を受け渡しする。

これを行うことで、ユーザーの認可のもとで別のサービスの管理するCRUD操作などを行えることになります。
②で同意したら、ユーザーは外部サービスにパスワードを教えること無く認可情報の移譲(③)ができます。
また、認可情報は有効期限を設定したり、認可情報の適用範囲を指定したりしてユーザーは外部サービスにすべての権限を渡すこと無く、必要最低限の権限のみを移譲することができます。
これがOAuthがベーシック認証に比べて柔軟かつセキュアと呼ばれる所以(③)ですね。

ざっくりいうとOAuthは認可を行うために用いられています。

認証と認可について

認証(Authentication)と認可(Authorization)の違いがあまりわかっていなかったので、まとめ。

認証は、ざっくりいうと 本人確認のことです。認証でエラーが出た時は、「あなたが誰だかわかりませんよ」のような意味になります。

認可は、ざっくりいうと 特定のリソースへのアクセス権限の付与のことです。認可でエラーが出た時は、「あなたが誰だかは分かるけど、許可が与えられていませんよ」のような意味になります。なので、 認証済みの利用者に対して、何らかのサービスの利用やリソースへのアクセスなどに対する権限を与えたりすることを指します。

AさんはBさんとFacebookの友人なのでBさんの友達公開のフィードまで見ることが出来るとします。
このとき、AさんがAさんであると確認することが認証で、AさんはBさんと友達なので閲覧可能という制御を行うことが認可です。

似たような2つの言葉ですが、これらは明確に区別しましょう。

ベーシック認証とは

ベーシック認証について簡単に。

Wikipediaによると、ベーシック認証とは、ユーザー名とパスワードの組をコロンでつなぎ、Base64でエンコードして送信する。Webサーバーおよびブラウザで対応しているため、広く使われている。

盗聴や改竄が簡単であるという欠点を持つので、セキュリティ的にはよろしくない。
詳しくはWikipediaを参照のこと。
staging環境のようにある一定の人しか見ないって時は、ベーシック認証で済ませることが多いですね。

OAuthの登場人物

OAuthには、

OAuth Service Provider(以下、Provider)
OAuth Consumer(以下、Consumer)
User

と大きく分けて3つの登場人物がいます。

(以下ゼロから学ぶOAuthより引用)

1のProviderは、ユーザーの認可情報を第三者に渡すサービスのこと。
2のConsumerはService Providerから認可情報を受け取り、ユーザーに代わって色々な情報にアクセスしたり変更、追加を行ったりするサービスのこと。
3のUserはService ProviderがConsumerに認可情報を渡すことを許可したり、すでに受け渡した認可情報を無効にするといったことができます。

ログインとOAuth

ログイン周りのAPIを考える際に、真っ先に検討すべきがOAuthという標準的な仕様です。
理由は、現在のWeb APIにおいて非常に広く一般的に利用されているからです。

先ほども書いたように、OAuthは第3者に公開されるAPIにおいて認可を行うために使われます。
FacebookがAPIを公開してて、自分の作ったWebサービスAがそれを利用した機能を提供していたとします。
Facebookに登録しているユーザーはサービスAを使う時に、サービスAはFacebookにアクセスして、そのユーザー情報を利用したいはずです。
そうした時に、サービスAに対して、そのユーザーがFacebookに登録している情報を利用してよいかの許可を与えることができる仕組みがOAuthです。
おさらいしたところで、Facebookログインを例にして、OAuthのおおまかな流れを見ていきましょう。

先ほどの登場人物の例で言うと、FacebookはProvider、サービスAはConsumer、ユーザーがUserになります。

ConsumerはProviderからあらかじめOAuth許可を得ます。
UserはサービスAに対して、「Facebookのリソースにアクセスしてください」とお願いをします。
サービスAはUserに対して、「それではFacebookにアクセスの許可をもらってください」とお願いをします。
UserはFacebookに対して、「サービスAのリソースへのアクセスを許可のお願い」をします。
FacebookはUserに対して、「それではトークン(以下、アクセストークン)をサービスAに渡してください」とお願いをします。
UserはサービスAに対して、「アクセストークンを使ってアクセスしてください」とお願いをします。
トークンを持っているサービスAはFacebookに対して、「リソースをください」とお願いをします。
FacebookはサービスAに対して、「どうぞ」とリソースへの許可を出します。

ポイントは、UserはFacebookの パスワードを入力する必要がない点です。Facebookログインをしようとしているサービスにはパスワードが渡ることはないです。
パスワードを入力する必要がないというのは、ボタンひとつでログインをできるということで、手軽なので一気に普及しましたよね。
QiitaではFacebookの他、TwitterやGithubログインもできるようになっています。

おわりに

今回は第三者向けのAPIを使う場合のケースについて見てきました。
他にも自社開発のクライアントアプリのときには、OAuthのエンドポイントはどうするのか、アクセストークンの有効期限はどうするのかなどをより考えていかないといけません。(が、今回は割愛)
以上参考になれば幸いです。