この前Draft 10の日本語訳が発表されたと思ったら、Draftが更新されて11になりました。
draft-ietf-oauth-v2-11 - The OAuth 2.0 Authorization Framework
3行でいうと
- Access Tokenを返すタイミングでtoken_typeパラメータが追加されたけど、中身はTBD
- ClientID/Secret以外でClientを特定するあたりの説明が追加された
- WWW-Authenticate Response Headerが少し変わった
って感じです。これだけで満足した人は帰って良し！
ゆっくり見たい人は続きをどうぞ。
差分チェック
Diffを見ましょう。
Diff: draft-ietf-oauth-v2-10.txt - draft-ietf-oauth-v2-11.txt
んー、とりあえずDocument Historyを見ましょう。
-11
o Many editorial changes. Fixed user authorization section
structure. Removed unused normative references. Adjusted
language regarding single use of authorization codes.
省略
o Fixed header ABNF.
ABFNってなにかについてはこちら。
"6.2. The WWW-Authenticate Response Header Field"の説明が変わっている部分ですね。
o Change access token description from shared symmetric secret to
password.
表現の変更。省略。
o Moved access grant 'none' to a separate section, renamed to
'client_credentials'.
grant_typeパラメータが'none'のときの説明が、3.2. Client Assertion Credentialsに説明が移されました。
ちなみに、和訳のgrant_typeパラメータが'none'のときの文言は？
アクセス許可タイプとして none を指定して (アクセス許可を含めずに) アクセストークンを要求する場合, それは自身のコントロール下にある保護リソースや, 他のリソースオーナーが (本仕様のスコープ外の方法で) 事前に認可サーバーと調整を終えている保護リソースに対するアクセス要求を意味する. 」
The OAuth 2.0 Protocol
としか書かれていませんでしたが、ちょっと補足もされている模様。あとで見ましょう。
o Demoted the HTTP status code requirement from MUST to SHOULD in
protected resource response error.
6.2.1. Error CodesのあたりでMUSTからSHOULDに変更。
o Removed 'expired_token' error code.
6.2.1. Error Codesでinvalid_tokenにexpiredの場合も含まるようになりました。
o Moved all the 'code_and_token' parameter to the fragment (from
code being in the query).
response typeが'code_and_token'のとき、codeがクエリパラメータでtokenがURIフラグメントにつけることになってたのが、両方ともフラグメントに含まれるようになりました。
o Removed 'assertion_type' parameter (moved to 'grant_type').
assertionを使ってtokenエンドポイントにアクセスするときの'assertion_type'パラメータが'grant_type'に変更。
o Added note about redirecting to invalid redirection URIs (open
redirectors).
4.1のあたりに書いています。
The authorization server SHOULD NOT redirect
http://tools.ietf.org/html/draft-ietf-oauth-v2-11#section-4.1
the user-agent to unregistered or untrusted URIs to prevent the
endpoint from being used as an open redirector. If no valid
redirection URI is available, the authorization server SHOULD inform
the end-user of the error occured.
エンドユーザー認可エンドポイントへのリクエストで、callbackにおかしなURIが付いてきたときなど、エラーだからってそのまま戻したらいかんというお話ですね。
o Removed bearer token section, added new required 'token_type'
parameter with extensibility.
Draft 10では、こんな感じで書いてありましたね。
アクセストークンはbearer tokenとして機能し, アクセストークンのトークン文字列は共有対称鍵として機能する. このことから, アクセストークンをその他の鍵と同じように扱う必要がある (例えば, エンドユーザーのパスワードのように). アクセストークンはセキュアでないチャンネルを平文で送られるべきではない (SHOULD NOT).
The OAuth 2.0 Protocol
このへんがごっそりお亡くなりになり、こういう書き方に代わりました。
The method in which the client utilized the access token to
http://tools.ietf.org/html/draft-ietf-oauth-v2-11#section-6
authenticate with the resource server depends on the type of access
token issued by the authorization server.
拡張性を持たせたってことですね。わかります。
消えたbearer tokenはこっちにあります。
draft-ietf-oauth-v2-bearer-01 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
これもあとで読みましょう。
エラーURIはこんな感じでした。
error_uri 属性は, エラーに関する情報をもつ解読可能なウェブページを識別するURIを提供し, エンドユーザーにエラーに関する追加情報を提供するために使用される. もし値が絶対URIでなければ, それはリクエストされた保護リソースに対する相対URIである.
The OAuth 2.0 Protocol
で、これが絶対URIだけになりました。
In addition, the resource server MAY include the
http://tools.ietf.org/html/draft-ietf-oauth-v2-11#section-6.2
"error_description" attribute to provide a human-readable
explanation, and the "error-uri" attribute with an absolute URI
identifying a human-readable web page explaining the error.
あれ？human-readableっていうけど、ユーザーに見せるためでしたっけ?
このへんはベストプラクティスというかうまい使い方を提示してもらえるとありがたいですね。
o OAuth 2.0 HTTP authentication scheme name changed to 'OAuth2'.
WWW-Authenticate headerにOAuthではなくOAuth2ってついてくるように変更。
o Dropped the 'WWW-Authenticate' header field 'realm' parameter.
realmパラメータがお亡くなりに。
o Removed definition of access token characters.
Access Tokenを使ったRequestの説明がなくなったので「HTTP Headerに載せるんだからこういう文字列になります」みたいな説明もいなくなりました。
o Added instructions for dealing with error and an invalid
redirection URI.
これに対応する文言はこちらですね。
The authorization server SHOULD NOT redirect the user-agent to unregistered or untrusted URIs to prevent the endpoint from being used as an open redirector.
If no valid redirection URI is available, the authorization server SHOULD inform the end-user of the error occured.
gdgdしすぎ。まとめると・・・
ということで、大事なのはこの辺ですね。
- 4.2. Authorization Responseにtoken_typeパラメータ追加
- 5.2. Access Token Responseにtoken_typeパラメータ追加
- 6.1. Access Token Types
token_typeってのはAccess TokenのTypeで、一緒に返されるわけですね。
中身は6.1に書いてありますが、今はTBDです。
Access Tokenが返される可能性がある4.2,5.2にしれっと追加されています。
- 6.2. The WWW-Authenticate Response Header Field
ちょっとすっきりした気がします。
- 3.2. Client Assertion Credentials
ClientがSecretを安全に保存できないような場合はSecret持つべきじゃないって話は前からあります。今回は、ClientがAssertion Formatをclient_assertion_typeパラメータとして指定し、Client Assertion Credentialをclient_assertionパラメータで指定します。
ServerがそのAssertion Formatをサポートしてたら、Clientを識別できますねって話です。
しかし注意。Authorization CodeをもらうときはClient ID必須です。なので、Client Assertion Credentialを使う場合でもそれに紐づくClient IDが必要だということ。「マッピング仕様外。だけど必要」みたいな感じで書いてあります。また別の機会にこのへん突っ込んで調べたいですね（って言ってたいてい調べないパターンorz）
いつになったら仕様決まるんでしょう？なんて言うのは簡単ですが、そんなこと言うならMLに突っ込んでいって手伝えって話ですね。
Bearer Tokenについてはそんな長くないですが、宿題で。ではまた。
