Hatena::ブログ(Diary)

Yet Another Hackadelic

2009-09-14

Identity Conference #6 開催告知

アイデンティティファンの皆様*1お待たせ致しました。

にて開催告知を出しました。

日時
10/9(Fri) 19:00-21:00
場所
株式会社 DeNA 12F セミナールーム 1213

で今のところ勝手に決めた仮タイトル。

  • 何か (仮) - (hiroki さん)
  • OpenID Contract Exchange の現在 (仮) (=nat さん)
  • OpenID UX (仮) (=ritouさん)
  • OpenSocial RESTful API と OAuth (仮) (=zigorou)

UX の仕様なんだけどこれは全然読んだこと無いので Identity 界の若手ホープである id:ritou さんに話して頂けたらなとか思うのですが、ついでに OAuth (と Hyblid) についても。

また =nat さんには Contract Exchange と Artifact Binding についてお話頂けると幸い。

とりあえず自分は OpenID からはちと離れて、最近仕事でやってる OpenSocial RESTful API の実装と OAuth について話せる範囲で話そうかなと思ってるけど、進捗次第でネタを変えるかも。

本当は XRD についても聞きたいのですが、=nat さん以外に Authority が見当たらないので誰か勇者求む。

なお、=tkudos 先生は今回はお休みです。予めご了承下さい^^

*1:誰?w

2009-08-11

OAuth Core 1.0 Revision A (2)

d:id:ZIGOROu:20090811:1250008682 の続き。

パラメータ

5. Parameters の辺りの話。

Consumer のリクエストパラメータ

以下のいずれかで。

  1. Authorization ヘッダにぶち込む (OAuth HTTP Authorization Scheme)
  2. application/x-www-form-urlencoded 形式の POST
  3. QUERY_STRING

将来的な拡張を見越して Authorization ヘッダは使うべきじゃない。

SP のレスポンスパラメータ

こんな感じ。

oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b
OAuth HTTP Authorization Scheme

リクエストヘッダに Authorization ヘッダを用いて、レスポンスヘッダに WWW-Authenticate ヘッダを用いる事によって OAuth のパラメータのやりとりする方式。

リクエストに使う Authorization ヘッダはこんな感じになる。

Authorization: OAuth realm="http://sp.example.com/",
oauth_consumer_key="0685bd9184jfhq22",
oauth_token="ad180jjd733klru7",
oauth_signature_method="HMAC-SHA1",
oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
oauth_timestamp="137131200",
oauth_nonce="4572616e48616d6d65724c61686176",
oauth_version="1.0"
  • パラメータ用のエンコーディングして
  • key-value は = で対応して
  • ', ' でセパレート
  • オプションで realm もつける

でレスポンスの時はこんなのを SP が付けてくる。

WWW-Authenticate: OAuth realm="http://sp.example.com/"

OAuth を用いた認証

6. Authenticating with OAuth の辺りの話。

ユーザーの Credential を用いる事無く、Consumer がユーザーの代わりに SP の Protected Resources にアクセスする為に二つの Token を用いると。

Request Token
ユーザーに Protected Resources へのアクセス認可を求める為に Consumer によって用いられる値で、その認可が得られたら Access Token へと交換する為に用いられる。適切な有効期間を設定した方がいい。
Access Token
ユーザーの代わりに SP の Protected Resources にアクセスするために Consumer によって用いられる値。Access Token はアクセス可能な Protected Resources に制限があるかもしれないし、有効期間にも制限があるかもしれない。ユーザーによって無効にされる場合もある。

で、OAuth の Authentication メカニズムはざっくり言えば3つのステップ。

  1. Consumer がユーザーから未認可の状態の Request Token を SP から得る
  2. User が Request Token を認可する
  3. Consumer は SP とユーザーによって認可された Request Token を Access Token に交換する

って感じ。

OAuth Core 1.0 Revision A (1)

d:id:ZIGOROu:20090811:1250006392 を適宜参照しつつ。自分用のメモです。

用語

3. Definitions より、抑えておくべきものだけ。

Service Provider
OAuth 使ったアクセスを許可するサービス。SP と略。
User
SP のアカウント持ってるユーザー
Consumer
ユーザーに代わって OAuth を使い SP にアクセスするウェブサイトまたはアプリケーション
Protected Resource(s)
SP によって制御されるデータで、Consumer は認証を通じてアクセス可能。
Consumer Key
SP に対して自身を識別する為に Consumer により用いられる値Provider.
Consumer Secret
Consumer Key の所有を確立するために Consumer によって用いられるシークレット
Request Token
ユーザーからの認可を得る為と Access Token に交換する為にに Consumer によって用いられる値
Access Token
ユーザーの持つ SP のクレデンシャルを用いる代わりに、ユーザーの代わりに Protected Resources にアクセスする為に Consumer によって用いられる値
Token Secret
与えられた Token の所有を確立する為に Consumer によって用いられるシークレット
OAuth Protocol Parameters
oauth_. から始まる

お約束とか

4. Documentation and Registration

Consumer Secret は Consumer と SP 以外の誰かに知られちゃ駄目です。

OAuth の三つの Request URL
Request Token URL
未認可の Request Token を得る為に用いられる URL で 6.1 に書いてある
User Authorization URL
Consumer のアクセスに対する User の認可を獲得する為に使われる URL で 6.2 に書いてある
Access Token URL
ユーザーによって認可済みの Request Token を Access Token と交換する為に使われる URL で 6.3 に書いてある
SP がやるべきこと

Consumer Key, Consumer Secret を何らかの方法で SP-Consumer 間で共有できるような枠組みを提供しつつ、

  • 三つの Request URL を提供する。対応する HTTP Method とかも明示する。
  • SP が対応する署名方式を明示する。
  • 他に何か拡張パラメータがあれば明示する。oauth_ で始まっては駄目。

OAuth Sequence Diagram Template


OAuth Sequence Diagram Template

OAuth Sequence Diagram Template

とりあえず、OAuth のお勉強用にテンプレ化。Web Sequence Diagrams すげー便利だなー。

participant User
participant Consumer
participant "Service Provider"

note over Consumer
  6.1 Obtaining an Unauthorized Request Token
end note

Consumer->"Service Provider": "6.1.1. Consumer Obtains a Request Token"
activate "Service Provider"
"Service Provider"->Consumer: "6.1.2. Service Provider Issues an Unauthorized Request Token"
deactivate "Service Provider"

note over Consumer
  6.2 Obtaining User Authorization
end note

activate Consumer
Consumer->User: "6.2.1. Consumer Directs the User to the Service Provider"
deactivate Consumer

activate User
User->"Service Provider": "Redirect to Service Provider"
deactivate User

activate "Service Provider"
"Service Provider"->User: "6.2.2. Service Provider Authenticates the User and Obtains Consent"
deactivate "Service Provider"

activate User
User->"Service Provider": "Authenticate and Consent"
deactivate User

activate "Service Provider"
"Service Provider"->User: "6.2.3. Service Provider Directs the User Back to the Consumer"
deactivate "Service Provider"

activate User
User->Consumer: "Redirect to Consumer"
deactivate User

activate Consumer

note over Consumer
  6.3 Obtaining an Access Token
end note

Consumer->"Service Provider": "6.3.1. Consumer Requests an Access Token"

deactivate Consumer

activate "Service Provider"

"Service Provider"->Consumer: "6.3.2. Service Provider Grants an Access Token"

deactivate "Service Provider"

SEE ALSO

2008-12-11 分かりやすい餌に食いついた

OpenID, OAuth, OpenSocial とかその辺りを包括的に話すコミュニティが出来ました

昨日の idcon #4 で agektmr さんと話してて、題目の通り DataPortability 的な何かを横断的に話せるコミュニティ無いから作ってみたよーと言う話を聞いたので、今日から具体的に動き始めてみました。

と言う訳で Google Group と IRC をとりあえず開設。

その辺りに興味のある人や、思いっきり実装してますぜって人まで広く参加して頂けるといいなと思います。

来年一月くらいに、勉強会的な何かを開きたいと思います。