OAuth 2.0周りの仕様ドキュメントについて

気になってる方々、最新の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

ではまたー。