WebAuthenticationBroker を使用して OAuth による認可処理を Windows ストアアプリ内に組み込む

Windows ストアアプリ開発の話です。 Windows 8.1 および Windows Phone 8.1 を対象とした内容です。 (8.0 以前あるいは 10 以降については触れません。)

「Authentication and User Identity (HTML)」に書かれているように、Windows ストアアプリ内にユーザー認証の機能を組み込むための選択肢はいろいろあります。このエントリでは、その中の一つである Web 認証ブローカー (Web authentication broker) について紹介します。

Web 認証ブローカー (Web authentication broker) の概要

Web 認証ブローカーは、OpenID や OAuth などのインターネット経由の認証プロトコル *1 を使うオンライン ID プロバイダーに接続してユーザー認証する (あるいは認可を得る) 際に利用できる機能です。

OAuth などのプロトコルでは、クライアントに許可を与えるためにユーザー (OAuth ではリソース保持者) がサーバー (ID プロバイダー) の web ページ上で操作する必要があります。ユーザーにサーバーの web ページを表示するためにアプリ内に web ビューを表示して操作させる場合もありますが、自前で web ビューを用意する代わりに Web 認証ブローカーを使用することができます。

クイックスタート: オンライン ID プロバイダーへの接続 (Windows)

Web 認証ブローカーの仕組みなどは、次のページを見ると良いでしょう。

Web 認証ブローカーの使い方

OAuth 1.0 Protocol を用いて認可を得る場合を例に、どのように web 認証ブローカーを使用するかを見ていきます。

前準備

Web 認証ブローカーを使用する前に、予め Temporary Credentials を取得しておきます。このとき、oauth_callback パラメータによりコールバック URI を指定できますが、任意の URI (「http://localhost/」など) を指定して良いです。

サーバー側が対応しているのであれば WebAuthenticationBroker.getCurrentApplicationCallbackUri メソッドの返り値 (「ms-app://s-1-15-2-9999-999999999-999999-99999/」みたいな URI) を使うのが良いです。ただ、サーバー側が「http(s)」プロトコルしか許可していない場合もありますので、その場合は適当な http プロトコルの URI を指定しましょう。

Web 認証ブローカーによる Resource Owner Authorization

Temporary Credentials を取得した後、リソース保持者による認可処理があります。すなわち、ユーザーをサーバーに送り、リクエストを認可してもらう必要があります。ここで web 認証ブローカーを使用できます。

Windows 8.1 プラットフォーム用: WebAuthenticationBroker.authenticateAsync メソッド
Windows Phone 8.1 プラットフォーム用: WebAuthenticationBroker.authenticateAndContinue メソッド

Web 認証ブローカーには、最初にユーザーに表示する web ページの URI (OAuth では Resource Owner Authorization endpoint URI) と、認可された後のリダイレクト先 URI (Temporary Credentials 取得時に指定したコールバック URI) を指定します。

var Uri = Windows.Foundation.Uri;
var WebAuthenticationBroker = Windows.Security.Authentication.Web.WebAuthenticationBroker;
var WebAuthenticationOptions = Windows.Security.Authentication.Web.WebAuthenticationOptions;
var WebAuthenticationStatus = Windows.Security.Authentication.Web.WebAuthenticationStatus;

// はてなの OAuth の場合。 `tempCred.identifier` は先に取得しておいた temporary credentials の identifier。
var startUri = new Uri("https://www.hatena.ne.jp/oauth/authorize?oauth_token=" + encodeURIComponent(tempCred.identifier));
// Temporary credentials 取得時に `oauth_callback` で http://localhost/ を指定していた場合。
var endUri = new Uri("http://localhost/");

// WebAuthenticationBroker が authenticateAndContinue メソッドを持っているかどうかで処理を変える。
var authenticateAndContinue = WebAuthenticationBroker.authenticateAndContinue;
if (authenticateAndContinue) {
    // Windows Phone 8.1 用
    authenticateAndContinue(startUri, endUri, null, WebAuthenticationOptions.none);
        // 結果の受け取り方は下の記述を見ること。
} else {
    // Windows 8.1 用
    WebAuthenticationBroker.authenticateAsync(WebAuthenticationOptions.none, startUri, endUri).done(function (result) {
        if (result.responseStatus === WebAuthenticationStatus.success) {
            // `result.responseData` にはリダイレクト先 URI 文字列が入っている。
            // 例 : "http://localhost/?oauth_token=xxxxxxoauth_verifier=xxxxxx"
        } else {
            // 失敗 (ユーザー操作で戻って来た場合など。)
        }
    }, function (err) {
        // 失敗 (HTTP レベルでのエラーが発生した場合など。)
    });
}

Windows Phone 8.1 でのレスポンスの受け取り方

Windows 8.1 の場合は、WebAuthenticationBroker.authenticateAsync メソッドを呼ぶとアプリ内にサーバーのページが表示され、ユーザーによる認可が完了すると Promise から結果を受け取ることができます。

一方、Windows Phone 8.1 では、WebAuthenticationBroker.authenticateAndContinue メソッドを呼ぶと一旦アプリが停止してアプリの外部でサーバーのページが表示され、ユーザーによる認可が完了するとアプリがアクティベートされます。メモリ使用量を抑えるために Windows Phone プラットフォームではこのような挙動になっているようです。

authenticateAndContinue メソッドのように xxxAndContinue という名前のメソッドがいくつかありますが、それらのメソッドを呼びだした後の結果はアクティベーションイベントとして受け取ることができます。 authenticateAndContinue メソッドではなくファイルピッカーの例ですが、次のページが参考になります。

ファイルピッカーの呼び出し後に Windows Phone アプリを続行する方法 (HTML) - Windows app development

XAML 版なので直接は利用できませんが、次のページの情報も参考になります。

AndContinue メソッドの呼び出し後に Windows Phone ストアアプリを続行する方法 (Windows)

ページナビゲーションをサポートするアプリの場合、次のような感じで WinJS.Application の activated イベントのリスナーを登録し、アクティベーションの情報を WinJS.Navigation.navigate メソッドに渡すようにします。

var SESSION_STAT_NAV_HISTORY = "nav_history";

var activation = Windows.ApplicationModel.Activation;
var app = WinJS.Application;
var nav = WinJS.Navigation;
var sched = WinJS.Utilities.Scheduler;
var ui = WinJS.UI;
var activationKinds = Windows.ApplicationModel.Activation.ActivationKind;

function activateOnLaunchOrContinuationProcs(args) {
    if (args.previousExecutionState !== activation.ApplicationExecutionState.terminated) {
        // TODO: This application has been newly launched. Initialize your application here.
    } else {
        // TODO: This application has been reactivated from suspension. Restore application state here.
    }

    // Optimize the load of the application and while the splash screen is shown, execute high priority scheduled work.
    ui.disableAnimations();
    var p = ui.processAll().then(function () {
        var url = Application.navigator.home;
        var activationKind = args.kind;
        var activatedEventArgs = args;
        // アクティベーションの情報。 `xxxAndContinue` メソッドの結果もここに含まれる。
        var initialState = { activationKind: null, activatedEventArgs: null };
        var navHistory = app.sessionState[SESSION_STAT_NAV_HISTORY];
        if (navHistory) {
            url = navHistory.current.location;
            initialState = navHistory.current.state || initialState;
        }
        initialState.activationKind = activationKind;
        initialState.activatedEventArgs = activatedEventArgs;
        nav.history = navHistory || {};
        nav.history.current.initialPlaceholder = true;
        return nav.navigate(url, initialState);
    }).then(function () {
        return sched.requestDrain(sched.Priority.aboveNormal + 1);
    }).then(function () {
        ui.enableAnimations();
    });
    return p;
}

app.addEventListener("activated", (args) => {
    // Windows.ApplicationModel.Activation.IActivatedEventArgs インターフェイスを実装したオブジェクト。
    var activatedEventArgs = args.detail;
    switch (activatedEventArgs.kind) {
        case activationKinds.launch:
        case activationKinds.pickFileContinuation:
        case activationKinds.pickSaveFileContinuation:
        case activationKinds.pickFolderContinuation:
        case activationKinds.webAuthenticationBrokerContinuation:
            args.setPromise(activateOnLaunchOrContinuationProcs(activatedEventArgs));
            break;
        default:
            break;
    }
});

上のようにしてアクティベーションの情報を WinJS.Navigation.navigate メソッドに渡すようにすると、その情報がページコントロールにわたってくるので、ページコントロールの ready で次のように情報を受け取ることができます。

var ActivationKind = Windows.ApplicationModel.Activation.ActivationKind;
var WebAuthenticationStatus = Windows.Security.Authentication.Web.WebAuthenticationStatus;

WinJS.UI.Pages.define("/pages/auth/auth.html", {
    ready: function (element, options) {
        // Continuation handlers are specific to Windows Phone.
        if (options && options.activationKind === ActivationKind.webAuthenticationBrokerContinuation) {
            // Windows.ApplicationModel.Activation.IWebAuthenticationBrokerContinuationEventArgs インターフェイスを実装したオブジェクト。
            var eventArgs = options.activatedEventArgs;
            // eventArgs から WebAuthenticationBroker からの結果を取りだして処理する。
            var result = eventArgs.webAuthenticationResult;
            if (result.responseStatus === WebAuthenticationStatus.success) {
                // `result.responseData` にはリダイレクト先 URI 文字列が入っている。
                // 例 : "http://localhost/?oauth_token=xxxxxxoauth_verifier=xxxxxx"
            } else {
                // 失敗 (HTTP レベルでのエラーが発生した場合やユーザーがキャンセルした場合。)
                // ユーザーによるキャンセルと HTTP レベルでのエラーが発生した場合の区別ができなさそう？
                // (手元で試したところ HTTP レベルでのエラーでも `result.responseStatus` の値が 1 になっていた。)
            }
        }
    }
});

ちょっと面倒ですがしょうがないですね。

WebAuthenticationBroker から結果を受け取った後

ユーザーが認可を行った場合は WebAuthenticationBroker からの結果に oauth_verification が含まれているはずですので、それを使って Token Credentials の取得処理を行えば良いです。

サンプルプロジェクト

WebAuthenticationBroker を使用するサンプルプロジェクトがあります。 JS のものも他の言語のものもあるので参考になるでしょう。ただ、OAuth 周りの処理は完全ではなさそう (OAuth のパーセントエンコードの代わりに encodeURIComponent が使われていたりする) なので、あくまで参考程度に。

Windows 8 Web authentication broker sample in C#, C++, JavaScript for Visual Studio 2013

セキュリティ的な話

アプリ内に web ビューを表示する方法だと、アプリが信頼できないものの場合にパスワードが盗まれる可能性があるという問題があるのでセキュリティ的には外部ブラウザを使う方法を提供するべき (下記ページ参照) なわけですが、web 認証ブローカーについても同様の問題がありそうな気がします。

OAuthの認証にWebViewを使うのはやめよう - Shogo's Blog

Web 認証ブローカーは Windows 側が提供している API なので、「接続先 URL が表示される」 + 「Web 認証ブローカーを用いた場合と同様の表示をアプリ側が独自に実装できないようになっている」という条件が満たされれば外部ブラウザを使用するのと同等になるのかなーと思いますが。 *2

そもそも Android アプリと違って審査があって、要件に『4.3 アプリはユーザーのセキュリティ、Windows デバイス、システム、関連するシステムのセキュリティまたは機能を危険にさらしたり侵害したりしてはならない。また、Windows ユーザーまたは他の個人に被害を与える可能性があってはならない』ってのがあるから、パスワードを抜こうとするようなアプリは審査で落とされるから大丈夫なのかもですけど。

*1:OAuth は認証のためのプロトコルではなく認可のためのプロトコルであるが、ここでは深く踏み込まない。

*2:あんまり考えずに書いてます。

ひだまりソケットは壊れない

ソフトウェア開発に関する話を書きます。最近は主に Android アプリ、Windows アプリ (UWP アプリ)、Java 関係です。