OAuth入門【概要編】

OAuthを使ったサービス開発はしたことありますが、認可サーバーの実装はしたことなく、一度きちんと勉強することにしました。

勉強した内容をブログにまとめていきたいと思います。

ヨノ

認証・認可ってエンジニアとして必須科目的な印象があるので、ちゃんとやらなきゃな〜とは思っていたんですよね。

初回は概要編。

認証と認可とは？

「よりよくわかる認証と認可」がとってもわかりやすい。

参考リンクを見てほしいですが、ざっくり要約すると

認証
通信の相手が誰であるかを確認すること
認可
とある特定の条件に対して、リソースアクセスの権限を与えること。ここでは相手が「誰であるか」という考えはない。

「通信の相手が誰か」を確認するかどうかがポイント！

OAuth 2.0 登場人物

登場人物

リソース所有者（Resource Owner）
- 保護されたリソースへのアクセスを許可するエンティティー。ほとんどの場合リソース所有者は人であり、エンドユーザーと呼ばれる。
- 多くの場合、エンドユーザーはWebブラウザを使って認可サーバーとのやり取りをする
リソースサーバー (Resource Server)
- リソース所有者がアクセス権を持っているリソースをホストし、アクセストークンを用いたリクエストを受理してレスポンスを返すことのできるサーバー。
- アクセストークンを信頼するか最終的な決定権を持つ存在
- OAuth徹底入門セキュアな認可システムを適用するための原則と実践では保護対象リソースと言われている。
クライアント（Client）
- リソース所有者の許可を得て、リソース所有者の代わりにリソースサーバーに対するリクエストをするアプリケーション
- 主な責務は認可サーバーからアクセストークンを取得し、リソースサーバーに対して使うこと。アクセストークンの中身を知るべきではなく、意味不明な文字列として扱う。
認可サーバー（Authorization Server）
- OAuthの仕組みの中心的な役割を担うHTTPサーバー
- リソース所有者とクライアントの認証を行い、リソース所有者にクライアントを認可する仕組みを提供し、クライアントにアクセストークンを発行する
- 認可サーバーとリソースサーバー間のやり取りについてはRFC6749の仕様書の範囲外。認可サーバーはリソースサーバーと同一のサーバーでも異なるサーバーでも良い。単一の認可サーバーが複数のリソースサーバーにアクセス可能なアクセストークンを発行しても良い。

OAuth 2.0 とは？

OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソース所有者とHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.

引用元：RFC6749

OAuth 2.0 は認可プロトコル（委譲プロトコルとも言える）であり、リソースを管理している誰か（リソース所有者）がアプリケーションにオーナー自身のなりすましをさせるのではなく、リソース所有者の代わりとして対象のリソースへのアクセスを許可するための手段。

OAuth のプロトコルの目的は、アクセストークンをクライアントに取得させ、クライアントにアクセストークンを使わせてリソースサーバーにリソース所有者の代わりとしてアクセスさせること。

例えば、ユーザーの代わりにツイートしたり、過去のツイートを取得するアプリケーションを作りたいと思ったら OAuth 2.0 の出番です。

Twitterアカウントを持っているリソース所有者が、アプリケーションに「ツイート権限」や「タイムライン取得権限」を認可（委譲）して、アプリケーションはその証としてアクセストークンを受け取ります。そして、このトークンを使ってTwitterにリクエストを投げてツイートしたり、タイムライン取得できるようになるってわけです。

OAuth 2.0 フロー

OAuthのトランザクションはトークンの発行とトークンの使用の2つに分割でき、標準的なOAuthのトランザクションは次のフローになります。

リソース所有者はクライアントにリソース所有者の代わりとして振る舞ってほしいことを指示する。
例. 私の代わりに、Twitter上のタイムラインを取得してください。
クライアントは認可サーバー（Authorization Server）にリクエストをし、そこでリソース所有者にクライアントを認可するか判断させる
例. 〇〇アプリケーション（クライアント）にタイムラインの取得を許可しますか？といった画面を表示する
リソース所有者はクライアントを認可する
クライアントは認可サーバーからトークンを受け取る
クライアントはリソースサーバー(保護対象リソース)にトークンを提示する

基本的なフローは↑に貼ったシーケンス図の通りです。

このときポイントとなのは次の3つ。

ポイント

認可サーバーでのリソース所有者の認証はクライアントからは見えない。エンドユーザーのクレデンシャルをクライアントに知られることはない。
トークンの発行と使用が分離されているため、認証方法が変わっても、クライアントは影響を受けない。（発行されたトークンを使うだけだから）
認可サーバーでのリソース所有者の認証方法はなんでも良い。OAuthの仕様ではここでの認証技術には触れられていない。（OAuthは認可プロトコルで認証プロトコルではないから）
- ID/PASSでも、SSOでも証明書でもどんな認証方法でもOK

実際には、クライアントがアクセストークンを取得するフローには4種類あって、それぞれで若干手順が異なってきます。

各フローについては、別記事で詳しくまとめたいと思います。