気になってる方々、最新のSpecはこの辺ですよ。http://tools.ietf.org/id/oauth
http://tools.ietf.org/html/draft-ietf-oauth-v2 : The OAuth 2.0 Protocol
こいつの説明はやめときます。
http://tools.ietf.org/html/draft-recordon-oauth-v2-device : OAuth 2.0 Device Profile
OAuth Core 1.0a で定義されているフローはwebとclientの2つなわけです。
1.0aのClientのフローなんて手動のToken入力なんかが必要なので、まぁ使われないだろうなーとおもいつつ[Yahoo! JAPANではしの仕様に対応している|http://techblog.yahoo.co.jp/web/openid/oauth/]わけだったりしますが、最近までOAuth 2.0のSpecの中にdevice flowってのが入ってました。
が途中でSpecから抜かれました。
もっとも一般的なWeb Server ProfileやUser-Agent Profileに比べて、もっと検討ないと使われないよなーとか思っていましたが、D. Recordonが引き続きまとめていくようです。
+----------+ +----------------+ | |>---(A)-- Client Identifier --->| | | | | | | |<---(B)-- Verification Code, --<| | | | User Code, | | | | & Verification URI | | | Device | | | | Client | Client Identifier & | | | |>---(E)-- Verification Code --->| | | | ... | | | |>---(E)---> | | | | | Authorization | | |<---(F)-- Access Token --------<| Server | +----------+ (w/ Optional Refresh Token) | | v | | : | | (C) User Code & Verification URI | | : | | v | | +----------+ | | | End-user | | | | at |<---(D)-- User authenticates -->| | | Browser | | | +----------+ +----------------+ Figure 1: Device Flow
流れはほぼ1.0aのままですね。
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux : OAuth 2.0 User Experience Extension
Facebookの最近のしくみがOAuth 2.0を意識して作ってある(Specが変わったので準拠ではなくなってしもた)のはドキュメントを読まれた方はわかるかと思いますが、
Facebook独自のテンプレ出しわけパラメータってのがあることを知ってる方もいるでしょう。
こいつをUser Experience向上のための拡張としてまとめようとしているような動きも見られます。
OpenID UI Extensionと同様に、Language Preferenceなどと、テンプレ出しわけがセットになっています。
3. Display OAuth 2.0 user delegation flows are designed to work across a wide variety of screen sizes, device types, and contexts. The client MAY request a specific form factor of dialog from the authorization server based on what they feel is most appropriate. The client includes the following URI query parameter when constructing its request to the end-user authorization endpoint URI: display OPTIONAL. The most appropriate form factor for the authorization dialog. If the parameter is included in the request, the value MUST be set to one of the following: page A full-page authorization screen (the default). popup A compact dialog optimized for modern web browser popup windows. touch A mobile-optimized dialog designed for modern smartphones such as Android and iPhone. wap An extremely compact dialog optimized for older mobile web browsers.
ClientがProviderにテンプレを指定してやるって感じですね。
まぁ、popupかどうかの判定はそれで良いと思いますが、iPhone/AndroidについてはProvider側でも出しわけをデフォでやると思うので、優先度とかをどう定義するかってとこが気になりますね。
OpenIDのときに、Langの方は拡張で指定された値が最優先みたいにかいてありました。OAuthでもそうかな?あとで読んでみます。
あとは、FB仕様そのまま過ぎてパラメータにoauth_やxoauth_がつかないのかとかも微妙に気になります。別にシンプルな方がいいですが。
http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade : OAuth 2.0 Token Upgrade Extension
D. Recordonが書いてるSpec、もう一つありました。
OAuth 1.0系のTokenからOAuth 2.0のTokenへのUpgradeについての仕様みたいです。
これは、GoogleがOAuth WRAP対応を開始するっていう記事にあった「Bridge Profile」と呼ばれるものに近い気がします。
http://tools.ietf.org/html/draft-oauth-dyn-reg : OAuth Dynamic Client Registration Protocol
UMAがらみなのか。
6. Client Registration with Pushed Metadata This registration flow works as follows: 1. The client sends its metadata in JSON form to the client registration endpoint. The client MUST send its name, description, and redirection URI and MAY send a URI for its icon. The client MAY sign the metadata as a JSON Token issuer, using the mechanisms defined in [OAuth-Sig]. 2. The authorization server checks the data, verifying the signature as necessary, and returns a client identifier and an optional client secret. +--------+ +---------------+ | Client |--(A)--- Registration Request --->| Authorization | | | with Metadata | Server | | | | | | |<-(B)----Registration Response ---| | | | with Client ID Info | | +--------+ +---------------+ Figure 1: Client Registration Flow with Pushed Metadata
詳細まで読んでませんが、レスポンスにOptionalでexpires_inとかも使えるってことは、一時的なClientIDなんてのも作れそうですね。
さらに拡張して、前に聞いたClientIDから子供のClientIDをつくるみたいなこともできそう。。。
ちなみに、OAuthでもXRDを用いたDiscoveryはもっと使っていくべきだと思う。
http://tools.ietf.org/html/draft-campbell-oauth-saml : SAML 2.0 Bearer Assertion Profile for OAuth 2.0
Autonomous Profileに含まれるSAML-OAuth連携あたりのところをkwskまとめようとしてるもの?がこちらかも。
http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth : A SASL Mechanism for OAuth
初めてみたのが、SASL。「さする」って読んで良いのかしら。
----+ +--------+ +---------------+ | | |--(C)-- Authorization Request --->| Resource | | | | | Owner | |Plain | |<-(D)------ Access Grant ---------| | |OAuth | | +---------------+ |2.0 | | |(1) | | Client Credentials & +---------------+ | | |--(E)------ Access Grant -------->| Authorization | | | Client | | Server | | | |<-(F)------ Access Token ---------| | | | | (w/ Optional Refresh Token) +---------------+ | | | ----+ | | | | ----+ | | (Optional discovery) +---------------+ | | |--(A)------- User Name --------->| | | | Client | | | | | |<-(B)------ Authentication -------| | | | | endpoint information | Resource | |OAuth | | | Server | |over | |--(G)------ Access Token -------->| | |SASL | | | | | | |<-(H)---- Protected Resource -----| | |(2) +--------+ +---------------+ | ----+ Figure 1: Interworking Architecture
いろいろありますねぇ。
http://tools.ietf.org/html/draft-sakimura-oauth-requrl : Request by Reference ver.1.0 for OAuth 2.0
これも忘れてはいけない。
せっかくいろんな拡張かんがえてるんだし、こういうの使ってURL長に影響ないようにしとくべきだと思う。
とりあえずOAuth 2.0の最新Draft新しいめのやつらを紹介しました。
もっと最新の状況が気になる方はこちら!
oauth Discussion Archive - Date Index
ではまたー。