OAuth 2.0やOpenIDの最新動向に追いつくために勉強したことまとめ。

OAuthやOpenID、仕組みもよく知らずに使ってきた僕が、その最新動向に追いつくために勉強したことをまとめます。
きっかけは OpenID TechNight #7 をUstで見たことで、わからないことが山盛りだったので色々と調べてみた。

キーワードとしては、OAuth 2.0、OpenID Connect、Cloud Identity、RESTful API、といったあたりについて。それぞれ基本的なことと、Ustで話されてたことをまとめる。

OAuth 2.0

OAuth 2.0でWebサービスの利用方法はどう変わるか（1/3）- ＠IT
を先に読めばよかった。
簡単にまとめると、OAuth 1.0の問題点は3つあって。

  1. 認証と署名のプロセスが複雑
  2. Webアプリケーション以外の利用が考慮されていない
  3. リソースを取得するために、リクエストトークンとアクセストークンの両方が必要。
    • リクエストトークンを保持しておく必要があるので、セキュリティ的に悪し。
    • 認証サーバとリソースサーバの分離が難しい

それがOAuth 2.0になると、

  1. HTTPSを必須にし、署名をなくし、トークン取得も簡略化
  2. Webアプリも含め、4つのクライアントプロファイルを仕様化
    1. Webサーバ（Web Server）
    2. ユーザーエージェント（User-Agent）
    3. ネイティブアプリ（Native Application）
    4. 自立クライアント（Autonomous）
  3. アクセストークンのみでリソース取得が可能に


で、肝心のスライドの内容に入る。
OAuth 2.0 Updates #technight
気になったのは仕組みの話。P.23から。

  • API側はAuthorization ServerとResource Serverの2つに分けられる。
    • 二つの分離が容易に！
  • 処理の流れが、認証のプロセスのそれ（Core Spec）とリソースプロセスのそれ（Token Type Spec）で分かれてる。(P.28)
    • Core Specは、ユーザー（Resource Owner）とクライアントと認証サーバのやりとり。
    • Token Type Specは、クライアントとリソースサーバのやり取り。
  • Core Specのresponse_typeはcodeとTokenの2種類が主となる。(P.28)
    • 以降の話は聞けず。
  • Token Type SpecのTokenは、BearerとMACの2種類が主。(P.43)
    • このうちBearerがメインストリームになる。
      • Bearerは署名、リクエストトークン、token secretが不要。
      • OAuth1.0とは大きく異なる。

ちょっと追いきれなかったところが多いけど、Bearerの扱いを覚えるのが大事っぽいことはわかった。
（2011/08/08 13:00追記）@shingoymさんよりコメントで、このセッションの録画したUstのURLを教えていただきました。ありがとうございます。

（追記ここまで）

OpenID Connect

の前に、OpenIDとOAuthの違いをまず明確に。
発表者の@_natさんのブログの出番です。これも先に読んどけばよかった。
非技術者のためのOAuth認証(?)とOpenIDの違い入門 | @_Nat Zone
OpenIDの仕組みは、紹介状を発行して、本人の身元を保証するもの。今よく使われてるOAuth認証はそれとは違い、認証するサービス（Twitterとか）の合鍵を渡すようなものなので、悪用しようと思えばDMを盗み見たり勝手にtweetしたりできる。
自分もtwitter連携サービスの「http://hsksyusk.jeez.jp/yoroshikutanomimasuyo/」とか「http://hsksyusk.jeez.jp/sorosorocurrytabetai/」を作ってて、この二つのサービスはたいへん楽しいですし、ぜひご利用になっていただきたいのですけれども、これらを作りながら、この辺は危ないよなーと思ってた。
単に身元確認するだけなら、認証先で色々出来る権限なんて渡す必要ないよね。
OpenID Connectは、その人専用のロッカーの鍵を渡すイメージ。そこの中には、ユーザーが渡したいユーザーの基本情報が入ってる。
ロッカーには他にも、別のサービスからもらった資格情報や、他のロッカーの鍵を入れることが出来て、サービス側はそれを利用して他のサービスからリソースを取得したりということが出来る。


で、スライド。
OpenID Connect - Nat Sakimura at OpenID TechNight #7
上の記事と重なってる部分も多かった。そしてそれ以外は、あんまり理解できなかったという。
気になったところを書き出すと、

  • ロッカーの中に別のサービスの鍵を入れておいて、サービス側がその鍵を使って別のリソースを取得するのを、クレーム集約、分散クレームというらしい。
    • クレーム集約は、IdPがデータを集めてRelying Party（サービス？）に送るモデル。

IdP（Identify Provider）やServerとも呼ばれます。 ConsumerがEnd Userが所有するClaimed Identifierの暗号化された証明に対してコンタクトを取る相手がIdentify Provider（以下、IdP）です。 どのようにしてEnd Userが自分を認証するIdPに対して自分のIdentityを証明するかはOpenID Authenticationの範囲外です。
仕様から学ぶOpenIDのキホン (3/3)：OpenIDの仕様と技術（1） - ＠IT

      • OpenIDのサーバーがIdPっぽいのか。
    • クレーム分散は、Relying Partyがデータを集めるモデル。
      • Relying Partyってなに。
      • これ？

さて、FacebookはOpenIDという船に乗った初めての大企業ではなくて、すでにGoogle、Microsoftなど数社が採用している。しかし彼らのほとんどは”issuing parties”でしかない。つまりそのサイトのアカウントでほかのOpenIDサポートサイトにアクセスできるが、彼らは”relying parties, RP”ではないので、ほかのサイト/サービスで作られたOpenIDによるログインを受け入れない。だから、GmailのアカウントでFacebookにログインするのはOKだが、MicrosoftのOpenIDアカウントでGoogleのサービスを利用することはできない。
（中略）
Facebookはそもそも最初から、RPだ。つまり、“FacebookのID”というものはなくて、ユーザがすでに持っている（大学や個人の）メールアドレスがログインIDだ。だから、OpenIDをサポートしたからといって、失うものは何もない。
Facebookが最大のOpenID Relying Party(RP)になる | TechCrunch Japan

    • Relying Partyが例えばFacebookだとすると、IdPがOpenIDで、自分がOpenIDに「Facebookが他のリソースにアクセスする権限」を設定して、IdPがFacebookに権限を与えて、FacebookがTwitterとかMySpaceとかそういうIdPの情報を集めてきて使う、みたいなイメージかしら。
  • プロトコルの内容はよくわからず。

Cloud Identity

と、これもその前に、アイデンティティについて。
非技術者のためのデジタル・アイデンティティ入門 | @_Nat Zone

デジタル・アイデンティティは、ある人に対して提供されている属性の集合です。プライバシーの侵害を起こさないためには、対象としているひとやモノだけに属性が提供されるようにしなければなりません。したがって、デジタル・アイデンティティに対するアクセスに対しては、アクセス者を識別した上で、アクセス制御がなされなければなりません。

例えばOracleのパートナー企業の社員が、その企業向けに公開された情報を見るには、「XX会社の社員」という属性情報だけ提供すればよいのだよね。


で、それを踏まえてスライド。
Cloud Identity Summit 2011 TOI

サービスに提供するアイデンティティ情報を常に正確に保つためには、利用者の立場や与えられた職責の変化、あるいは利用者の参加・離脱に応じて、アイデンティティ情報を適時・的確に再設定する必要がある。これを実現するためのサービスがアイデンティティ・プロビジョニング・システムである。
http://www.computerworld.jp/topics/566/SOA/60789/SOA%E3%82%92%E6%8A%80%E8%A1%93%E9%9D%A2%E3%81%8B%E3%82%89%E6%94%AF%E3%81%88%E3%82%8B%E3%80%8C%E3%82%A2%E3%82%A4%E3%83%87%E3%83%B3%E3%83%86%E3%82%A3%E3%83%86%E3%82%A3%E7%AE%A1%E7%90%86%E3%80%8D%E3%81%AE%E9%87%8D%E8%A6%81%E6%80%A7

個人で使うwebサービスなんかは、使うときにユーザー登録すればいい。けど、企業で使うのであれば、社員が入社したらユーザーを作って、部署や役職ごとに権限を設定してっていうことが必要でそういうことをやるのがユーザープロビジョニングみたい。

  • SCIM?
    • ここから少しスライドを離れて、いろいろ資料を読んで、こうかな？って僕が思ったことです。
    • を考える前に、クラウド時代ってどういうこと？というのをイメージするといい。

@_natさんも引いていたCloud Identity Summit 2011のChuck Mortimoreさんのスライド"Open, Mobile, Social"から。
Open, Mobile, Social

昔はこう、企業の中と外には境界線があって、その中で完結してましたよね、と。

で、クラウド使うようになったら、境界はこう？

実際はこうじゃない？


日本の企業の中にいると、実感としてはないのだけど、世界的にはこういう感じなんだろうか。日本だと2番目の形に進みそうな気がする。企業毎に社内向けクラウドサービスが立ち上がって、ガラパゴス化していくという。
でも未来は3番目にあるんだろうね。


で。企業からクラウドサービスを使うんであれば、個人で使うみたいに個別にユーザー登録するんでもなく、企業内システム使うみたいに企業内でユーザープロビジョニングするわけにもいかない。クラウドサービスを使うためのユーザープロビジョニングをどうするかっていうのが問題としてあるっぽい。
これが標準化されると、企業がいろんなクラウドサービスを利用する上で、社員のユーザープロビジョニングするのが容易になる。


で、話はスライドのSCIMに戻る。

SCIM(Simple Cloud Identity Management

（スライドP.11）

  • Identity Managementのこれまでとこれから（P.25〜28）
    • これまではユーザーエージェントが企業内に限られてたけど
    • これからは外部サービスやモバイルアプリもエージェントとなって企業システムにアクセスしてくる。
      • その際に、これまでみたいなアクセス制限だけじゃなく、トークン管理が必要になる。
      • そこではAPI認証やアイデンティティの技術が必要になり、
        • OAuth 2.0やOpenID Connectが使われるんじゃないか。
    • さらにその後、人事システムやユーザープロビジョニングもSaasのものを使うようになり、
      • そこではSCIMが使われるんじゃないか。

質疑応答で、日本の大企業に導入するのにどう説得しようっていうような相談のような質問があったけど、たぶんその通りで、さっき書いたみたいにガラパゴス化すると思う。
一方でアメリカでも中小企業から導入が始まってるみたいな話があって、日本もそうなるんだろうな。
SIerカワイソス。
OpenID TechNightでのお話はここまで。

RESTful API

勉強会の中で何度も出てきてたRESTfulっていう言葉がよくわからなかったので調べてみた。
一番わかりやすかったのが、MySpaceが自前のAPIを説明したこの一文。

RESTful APIはHTTPリクエストによってネットワーク上のリソースを呼び出し、レスポンスとしてXMLドキュメントを受信します。
http://developer.myspace.com/Community/forums/p/7067/35155.aspx

REST自体の詳しい解説はこちら。合わせて読むと理解が深まった。
yohei-y:weblog: REST 入門
リソースっていうのは、天気情報サイトだったら「東京の天気予報」だったり、MySpaceで言えば例えば「あるアーティスト」の「ある楽曲」だったりといったもの。リソースは識別子（URI）を持つ。http://weather.yahoo.co.jp/weather/jp/13/4410.html とか。
これをHTTPリクエストであるGETを使って取ってきたりするのがREST。リクエストに使えるメソッドは他にPOST,PUT,DELETEがある、と。


で、RESTful APIに戻って。

REST Web service の最も純粋な形での具象実装は、次の 4 つの基本的な設計原則に従うようにすることを提言します。

  • 明示的に HTTP メソッドを使う
  • ステートレスにする
  • ディレクトリー構造に似た URI を公開する
  • XML、JSON (JavaScript Object Notation) のいずれか、またはその両方を転送する

RESTful Web サービスの基本

だと。
ここで出てきたステートレスがよくわからんかったのですが、これも同じブログが参考になった。
yohei-y:weblog: ステートレスとは何か
要はAPI側で処理状況を覚えておかないっていうことね。
たとえばTwitter APIで、タイムラインを取得するとき、今何ページ目まで読んだから次何ページ目を貰いに行くというのは、APIを使う側が覚えてる。


以上、長い上にまとめとかはありません。