oAuth の調査
oAuth という認証・認可のプロトコルに興味があり、調査している。
以下で認証と認可という言葉を使うので、まずここで整理する。
認証 (Authentication) と認可 (Authorization) は違う。
認証（Authentication）
そのユーザーが自分の物であると主張するIDに対して、そのIDが確かにそのユーザーの物であるということを保証すること
認可（Authorization）
認証されたIDを受け入れ、サービスに対して適切な権限を与えること
である。
oAuth というプロトコルをマッシュアップサイト作成時に使ってみることを考える。
プレイヤーは以下の 4種類。
1. End User
リソース所有者。Consumer にリソースを提供
2. Protected Resource
End User が Consumer に公開するリソース
3. Consumer
リソース処理者 (マッシュアップサイト)
4. Service Provider
リソース管理者 (マッシュアップされるサイト)
マッシュアップ時に問題になるのは、以下のことである。
Service Provider のリソースを利用するため、API を叩くとき、End User のユーザ ID とパスワードによる認証が必要である。多くの場合、そのアイパスは Consumer が管理することになる。
⇒ Consumer の管理リスク + End User のセキュリティリスクが高い。
このため、目標としては、
1. End User は Service Provider のサイトで認証したい。
2. Consumer は End User が Service Provider により認証されたユーザであることのみ知りたい。
3. End User は Consumer に自身が許可したリソースのみ認可したい。
ということになる。
この目標を達成してくれそうなのが、oAuth なのである。
ここで、oAuth による認証・認可フローを追ってみる。
1. End User は Consumer に Service Provider の Protected Resource 取得を依頼
2. Service Provider は Consumer に 401 (Unauthorized) + Request token
3. Consumer は Request token を End user に渡す。
4. End User は request token を使い、Service Provider と認証
5. Service Provider は End User に Access token 返却
6. End User は Consumer に Access token を渡す
7. Consumer は Access token を使い Service Provider に Protected Resource の取得を依頼 (⇒ OK!)
以上の過程で、上記の目標は達成可能である。
ここで、
に注意して欲しい。
後者より、oAuth は認証、認可どちらかに分類されるというより、リソースへのアクセス制御プロトコル、という位置付けが適当だろう。
oAuth の標準化と実装が進むと、ネットの世界でますます面白いことができるようになると思っており、とても期待している。
※本記事では以下を参考にしました。
OAuth Core 1.0 Draft 4
OAuth - リソースへのアクセスを代行するプロトコル
WebAPI のアクセス制御に使える OAuth という仕様
OAuthは熱いかも？な件に関して
OAuth の Auth は認証？認可？
