OAuth WRAP Profiles (翻訳、Javascript Profile も含む)

OAuth WRAP という新しい OAuth の仕様が話題になってるので、ちょっとドキュメントを訳してみました。

全部翻訳するのは大変なので、利用シーンごとに分けて作られている "Profile" というのだけをそれぞれ訳しています。(WRAP は Web Resource Authorization Protocol の略らしい)

Facebook Connect を置き換えるものとしても注目されており、Javascript 単体のアプリケーションなんかも想定してあります。今回翻訳したドキュメントでは、まだ Javascript Profile は定義されていないのですが、MLに仕様書のドラフトが添付されていたので、そちらも同時に訳しています。

Smart.fm でも Javascript アプリ上での認証はオープン化の key なので、特に Javascript Profile に注目しています。

Autonomous Client Profiles

認可サーバとクライアントの二者間で認可を行う。いわゆる 2-legged。Refresh Token は利用しない。

Client Account and Password Profile (5.1)

This is the simplest Profile. The Client is provisioned with an account name and corresponding password by the Authorization Server. The Client presents the account name and password to the Access Token URL at the Authorization Server in exchange for an Access Token.

もっとも単純なプロファイル。認可サーバが個別のクライアントアプリケーションごとにアカウント名とパスワードを振り分け、クライアントは Access Token 取得時にそのアカウント名とパスワードを認可サーバに提示する。

Assertion Profile (5.2)

This profile enables a Client with a SAML or other assertion recognized by the Authorization Server. The Client presents the assertion to the Access Token URL at the Authorization Server in exchange for an Access Token. How the Client obtains the assertion is out of scope of OAuth WRAP.

クライアントと認可サーバの間で SAML などのアサーションを確立し、クライアントは Access Token 取得時にそのアサーションを認可サーバに提示する。どのようにアサーションを確立するかは OAuth WRAP のスコープ外。

User Delegation Profiles

クライアントがユーザの権限で認可サーバにアクセスする。いわゆる 3-legged。Refresh Token を利用する。

Username and Password Profile (5.3)

While the User may use a username and password to authenticate to the Authorization Server, it is undesirable for the Client to store the User's username and password. In this profile the User provides their username and password to an application (Client) they have installed on their device. The Client presents a Client Identifier, the username and password (credentials) to the Access Token URL at the Authorization Server in exchange for an Access Token and a Refresh Token.

When the Access Token expires, the Client presents the Refresh Token to the Refresh Token URL at the Authorization Server in exchange for a new Access Token.

ユーザは認可サーバへの認証にユーザ名とパスワードを使うが、ユーザ名とパスワードをクライアント側に保存するのは好ましく無い。このプロフィールではユーザが自身のユーザ名とパスワードを自身のデバイスにインストールされたアプリケーションに入力することを想定している。クライアントは Access Token & Refresh Token 取得時に Client Identifier とユーザ名、パスワードを認可サーバに提示する。

Access Token の有効期限が過ぎた時には、クライアントは Refresh Token を認可サーバに提示して、新しい Access Token を取得する。

Web App Profile (5.4)

It is undesirable for a User to provide their Authorization Server username and password to web applications. Additionally, the User may authenticate to the Authorization Server using other mechanisms then a username and password. In this profile, a web application (Client) has been provisioned with a Client Identifier and Client Secret and may have registered a Callback URL.

The Client initiates the protocol by redirecting the User to the User Authorization URL at the Authorization Server passing the Client Identifier and the Callback URL. The Authorization Server authenticates the User, confirms the User would like to authorize the Client to access the Protected Resource, and generates a Verification Code. The Authorization Server then redirects the User to the Callback URL at the Protected Resource passing along the Verification Code.

The Client then presents the Client Identifier, Client Secret, Callback URL and Verification code (credentials) to the Access Token URL at the Authorization Server for an Access Token and a Refresh Token.

認可サーバのユーザ名とパスワードをWeb アプリケーションに提示するのは好ましく無い。またユーザはユーザ名とパスワード以外の方法で認可サーバへの認証を行う可能性もある。よってこのプロフィールではクライアントはあらかじめ Client Identifier と Client Secret を取得する。その時同時に Callback URL を登録することもある。

認可開始時に、クライアントはユーザを認可サーバにリダイレクトさせる。このとき Client Identifier と Callback URL をパラメータとして渡す。認可サーバはユーザの認証を行い、ユーザの同意を得て Verification Code を発行する。その後認可サーバはユーザを Callback URL にリダイレクトさせる。このとき Verification Code がパラメータとして付与される。

クライアントは Access Token & Refresh Token 取得時に Client Identifier、Client Secret、Callback URL、Verification code を認可サーバに提示する。

Rich App Profile (5.5)

This profile is suitable when the Client is an application the User has installed on their device and a web browser is available, but it is undesirable for the User to provide their username and password to an application, or the user may not be using a username and password to authenticate to the Authorization Server.

The Client initiates the protocol by directing the User's browser to the Authorization URL at the Authorization Server passing the Client Identifier and potentially a Callback URL. The Authorization Server authenticates the User, confirms the User would like to authorize the Client to access the Protected Resource, and generates a Verification Code. The Verification Code may be communicated back to the Client in a number of ways

(A) the Authorization Server presents the Verification Code to the User, who is instructed to enter the Verification Code directly in the Client; the Client reads the Verification Code from the title of the web page presented by the Authorization Server

(B) the Authorization Server redirects the User to the Callback URL that presents Client specific language for the User to enter the Verification Code into the Client;

(C) the Client has registered a custom scheme and the Authorization Server redirects the browser to the custom scheme that causes the User's browser to load the Client application with the Verification Code as a parameter.

The Client then presents the Client Identifier, Callback URL (if provided) and Verification code (credentials) to the Access Token URL at the Authorization Server for an Access Token and a Refresh Token.

このプロフィールでは、クライアントはユーザのデバイスにインストールされているアプリケーションであり、かつ Web ブラウザが利用可能な状況を想定している。もちろんユーザがユーザ名とパスワードをアプリケーションに渡すのは好ましく無い。またユーザはユーザ名&パスワード以外の方法で認証を行っている可能性もある。

クライアントはまず Web ブラウザを用いてユーザを認可サーバにリダイレクトさせる。このとき Client Identifier と Callback URL をパラメータとして渡す。(Callback URL は任意) 認可サーバはユーザの同意のもと Verification Code を発行する。Verification Code は以下のような方法でクライアントに渡される。

A) ユーザに Verification Code を提示して、ユーザがその Code をクライアントに入力する。もしくはクライアントが Web ページのタイトルから Verification Code を読み取る。

B) 認可サーバがユーザを Callback URL にリダイレクトさせる。ユーザはリダイレクト先 (おそらくクライアント側で用意した Web ページ) で Verification Code の入力を求められる。

C) クライアントは認可サーバに特別なスキーマを登録し、認可サーバはブラウザをそのスキーマにリダイレクトさせる。このスキーマへのリダイレクトにより、クライアントアプリケーションが起動され、パラメータとして Verification Code が渡される。

クライアントは Access Token & Refresh Token 取得時に Client Identifier、(もしあれば) Callback URL、Verification code を認可サーバに提示する。

Client App Profile

This profile is a suitable when the Client is an application that lives purely on the user's client - for example, on a desktop, or in JavaScript.

Because the entire source code for the Client is downloaded to the User's desktop or browser, it is not possible to protect the Client Secret. This profile allows for authorization while taking those security considerations into account. Because there is no Client Secret to ensure authenticity, both the Client and the Authorization Server should take some extra precautions when using this profile. Specifically, it should only be used when the risk of exposing the Access Token in a JavaScript environment is acceptable. To help mitigate this risk, it is strongly RECOMENDED that the Access Token have an expiration time on the order of a few hours.

If the Client wishes to obtain an Access Token with a much longer expiration time, they should make use of the "Client Refreshes Access Token" method within the Web App Profile.

このプロフィールではクライアントがデスクトップアプリや Javascript アプリなど、完全にクライアントサイドにある状況を想定している。

ソースコードは完全にクライアント上にダウンロードされるので、Client Secret を保護する方法は無い。そのためこのプロフィールではこれらのセキュリティ上の問題が考慮されている。このプロフィールを利用する際は、Client Secret を利用しない代わりに、クライアントと認可サーバ両サイドでなんらかの対策を行うおくべきである。特に Javascript アプリで利用する場合は、Access Token の漏洩が許容される場合にのみこのプロフィールが利用可能である。Access Token 漏洩リスクを軽減するため、Access Token は数時間程度で無効化することが望ましい。

クライアントが有効期限より長い間アクセス権を必要とする場合は、Web App Profile で定義された "Client Refreshes Access Token" のフローを利用するべきである。