最新のアプリ

  • [アーティクル]

Windows ストア アプリの認証と ID

Rachel Appel

Rachel Appel現在、非常に多くのアプリや Web サイトでは、なんらかのログイン処理または資格情報の入力が必要です。その理由の 1 つとして、多くのアプリや Web サイトでは、保存されているユーザー設定に基づいてエクスペリエンスをカスタマイズしていることが挙げられます。ユーザーはきわめて多数のサイトやアプリでサインインを求められるので、開発者はユーザーのサインインを簡略化する必要があります。この記事では、Microsoft アカウントまたはサードパーティによるログインを実現しながら、Windows プラットフォームでのアプリ認証の基本について説明します。また、スマート カード、バイオメトリック認証などの補助認証方法についても説明します。

最新のアプリの認証とユーザー ID

ユーザー資格情報の収集は、たいていの場合、ユーザーにとってはエクスペリエンスの充実ではなく負担の増加を意味します。そのため、ユーザーの資格情報を保存する必要がある場合は、資格情報を安全に保護しながらも利便性を損なわない方法で保存することをお勧めします。

信頼されたエンティティを利用してユーザー情報を管理および保存するには、Microsoft アカウント (旧 Windows Live ID)、Facebook、OAuth などの独立系資格情報プロバイダーの使用をお勧めします。このような資格情報プロバイダーを使用しても、永続的な個人用の UI をユーザーに提供することは可能です。また、ユーザーがすべてのパスワードを覚えているわけではないという現実に向き合いましょう。特に、使用頻度が低いサイトやアプリのパスワードは覚えていません。新しい資格情報を作成して覚えるようユーザーに求めると、ユーザー エクスペリエンスが低下します。この機能があるだけでも、アプリ ストアでの評価が低下する要因になり、開発者の期待とは逆の結果になってしまいます。

開発者の視点から見れば、ユーザーの資格情報を保存すると、Facebook ログインなどを使用する場合よりも、記述が必要なコード、テスト、バグ修正が増えます。また、ローカル データベースにログイン データを保存すると、セキュリティ侵害が発生するおそれもあります。マイクロソフト、Facebook、Twitter、OAuth、その他のサードパーティ製資格情報サービスなどの信頼できるエンティティを使用すれば、ユーザーと開発者両方のストレスを軽減できます。このようなサービスでは、情報のセキュリティを保つ適切なアルゴリズムを使用して、ユーザーの資格情報や個人情報を保存しています。開発者の側で必要な作業は API の呼び出しのみです。API を呼び出すだけで、あらゆる面倒な処理が片付きます。

Microsoft アカウントを使用する

Microsoft アカウントを使用する場合、ユーザーは Windows ログインと調和し類似しているログイン エクスペリエンスを期待します。そのため、資格情報の収集用 UI コントロールを独自に作成する代わりに、Microsoft アカウント API に付属する UI コントロールを使用することをお勧めします。さいわい、このようにするとコーディングも簡単になります。ログイン情報のコーディングは退屈な作業なので、Microsoft アカウント API などの API を使用して省略でき、また省略することをお勧めします。

ログインを要求する場合は、アプリの起動時にログイン UI を表示します。ユーザーがセッション間でサインイン状態を維持できる場合やログインする必要がない場合は、ログイン UI を設定ポップアップに追加します。また、ユーザーがサインアウトできることも忘れずに確かめます。多くのユーザーは気に入った Web サイトやアプリでサインイン状態を維持することを好むので、サインアウトは非常に忘れられがちです。

これは、携帯電話やデバイスをユーザー間で貸し借りする必要があるときに問題になることがあります。サインインした後にサインアウトできない場合、次のユーザーがアプリを使用して最初のユーザーになりすませるおそれがあります。一方、最初のユーザーからすれば、そもそもサインアウトできないので、場合によってはデバイスを貸し出せません。

アプリのどの画面でもユーザーが手軽に確認できる場所に、必ずサインイン状態を表示し続けます。サインイン状態の表示方法には、テキストを更新するだけの退屈な方法に限らず、ユーザーのアバターを表示する方法もあります。また、Microsoft アカウントを使用する場合は、OneDrive フォト ストレージの写真を表示してもよいでしょう。ユーザーが簡単にサインイン状態を確認して変更できる限り、自由に想像力を働かせましょう。一般的な手法では、アプリの右上隅にユーザーのアバター サムネイルを表示します。

Microsoft アカウント認証

Microsoft アカウント認証を使用すると、OneDrive、Outlook.com、MSDN サブスクリプション、Xbox、Windows 8 のデバイスやアプリなど、すべての Microsoft Live サービスで滑らかなサインオン エクスペリエンスを実現できます。

ユーザーの機密情報を含む可能性があるサービスを使用できるようにするには、オンラインでマイクロソフト デベロッパー センター (appdev.microsoft.com/StorePortals/ja-JP/Home/Index) にアプリを登録する必要があります。登録すると、アプリで Microsoft アカウント サービスを使用できるようになるので、アプリのユーザーがさまざまなリソースにアクセスできます。

個人情報にアクセスするサービスを開発するため、アプリ内で参照できる明確な "プライバシーに関する声明" を提供する必要があります。プライバシーに関する声明の作成でサポートが必要な場合は、myapppolicy.com (英語) または w8privacy.azurewebsites.net (英語) を活用すると声明の作成に役立ちます。プライバシーに関する声明が完成したら、設定ポップアップを使用して声明を表示できます。

最後に、ユーザーがサインインおよびサインアウトするためのコードを提供する必要があります。そのためには、サインイン ボタンを配置したポップアップ コントロールを使用できます (サインイン ボタンは、サインインするとサインアウト ボタンに変わります)。サインイン/サインアウト ボタンをクリックすると、サインインまたはサインアウトのうち対応する操作を実行するためのダイアログが表示されます。図 1 に、アカウント設定ポップアップを作成する XAML を示します。

図 1 アカウント設定ポップアップを作成するコード

<SettingsFlyout
  x:Class="App.Account"
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:local="using:App"
  xmlns:d="https://schemas.microsoft.com/expression/blend/2008"
  xmlns:mc="https://schemas.openxmlformats.org/markup-compatibility/2006"
  mc:Ignorable="d"
  IconSource="Assets/SmallLogo.png"
  Title="Account"
  d:DesignWidth="346">
  <StackPanel x:Name="accountSettings">
    <Button x:Name="SignInButton" Click="SignInClick" Content="Sign in" />
  </StackPanel>
</SettingsFlyout>

ご覧のとおり、これはボタンを配置したコントロールです。このボタンは、ログイン インターフェイスを起動するためにユーザーが使用する UI です。ポップアップにサインイン ボタンを配置することは慣行になっています。設定ポップアップの作成の詳細については、「JavaScript を使って構築した Windows ストア アプリのコントロールと設定を習得する」(msdn.microsoft.com/ja-jp/magazine/dn296546.aspx) を参照してください。サインイン ボタンのクリック イベントでユーザーをアプリにサインインさせるコードは、次のようになります。

private async void SignInButton_Click(object sender, 
  RoutedEventArgs e)
{
  LiveAuthClient authClient = new LiveAuthClient();
  LiveLoginResult authResult =
    await authClient.LoginAsync(new List<string>() 
   { "wl.signin", "wl.basic"  });
  if (authResult.Status == LiveConnectSessionStatus.Connected)
  {
    // Perform post authentication duties
  }
}

このコードは、ユーザーがまだサインインしていない場合に Microsoft アカウント サインイン画面 (通称、ログイン ページ) を表示します (図 2 参照)。ご覧のとおり、ログイン プロセスの実行に必要なコードはそれほどありません。LiveAuthClient の Session プロパティを使用すると、アプリ全体のセッション状態をクエリできます。

The Microsoft Account Sign-in Screen
図 2 Microsoft アカウント サインイン画面

HTML と JavaScript を使用しても同じ処理を実行できますが、手順はやや異なります。まず、[参照の追加] コマンドを使用して Windows Live SDK を参照します。次に、HTML 開発での慣行に従い、HTML ドキュメントで <script> タグを使用してスクリプトを参照します。

<script src="///LiveSDKHTML/js/wl.js"></script>

ただし、開発時はデバッグ バージョンの使用をお勧めします。デバッグ バージョンを使用する場合は、次の参照を使用できます。

 

<script src="//js.live.net/v5.0/wl.debug.js"></script>

図 3 は、ユーザーをサインインさせる WinJS コードを示しています。Microsoft アカウントを初期化できるように、またログイン時に発生するイベントをサブスクライブできるように、WL.init と WL.Event.subscribe を呼び出す必要があります。XAML アプリの場合、この初期化は必要ありません。ログイン イベントでは、接続状態の表示など、ログイン後に必要なあらゆる処理を実行できます。

図 3 ユーザーをサインインさせる WinJS コード

(function () {
  "use strict";
  WL.init();
  WL.Event.subscribe("auth.login", loginComplete);
  document.querySelector("#SignInButton").addEventListener("click",
    function () {
      login();
    });
  function loginComplete() {
    WinJS.log("User has signed in!")
  }
  function login() {
    var session = WL.getSession();
    if (session) {
      WinJS.log("You are already signed in!")
    }
    else {
      WL.login({ scope: "wl.basic" }).then(
        function () {
          // Perform post authentication duties
        },
        function (response) {
          WinJS.log("Could not connect, status = " + response.status);
        });
    }   
  }
})();

図 3 のコードは、対応する XAML コードと同じ処理 (実際のユーザーログイン処理) を実行します。使用する言語にかかわらず、wl.login メソッドにはスコープを渡す必要があります。スコープとはアクセス許可レベルです。つまり、スコープによって、ユーザーの代理としてアプリが実行できる処理の内容と実行場所を示します。ご想像のとおり、スコープはユーザーが指定します。開発者はユーザーを偽装して必要なすべての処理を試行できますが、Windows ランタイムにより、処理の続行前にユーザーの同意を得る必要があります。

Web 認証ブローカー (OAuth)

Microsoft アカウント、Facebook、Twitter、LinkedIn、OAuth といった客観的な集中型サードパーティ製資格情報サービスを使用することは、優れた認証戦略です。ユーザーがサイトのパスワードを覚えている可能性は、頻繁に訪れるサイトや好みのサイトほど高くなります。定評のある認証を使用すれば、開発者が取り組む必要があるインフラストラクチャ コードが減少し、ビジネス ロジックや UI 関連処理に割く時間が増えることにもなります。

Web 認証ブローカーは、認証の実行を簡略化する方法の 1 つです。Web 認証ブローカーを使用すると、ユーザー情報を安全に保存するための面倒な作業に対処する必要がなくなります。代わりに、すべての個人情報を適切に暗号化する必要があります。Web 認証ブローカーは、アプリと認証プロバイダーの間の連絡窓口です。また、複数のアプリにまたがるシングル サインオンを有効にする役割もあります。

コードでは、Web 認証ブローカーを呼び出して Facebook などの特定の認証サービスのダイアログ ボックスや Web ページを表示します (図 4 参照)。このダイアログ ボックスは、ユーザーがプロバイダーの Web サイトやアプリにログインする際に通常表示されるサインイン画面と同じです。多くの場合は、ダイアログ ボックスが自然にアプリに組み込まれて見えるようにカスタマイズできます。

図 4 Web 認証ブローカーを使用したサインイン

async public Task<string> WebAuthenticate(){
  string startURL =
    "https://<providerendpoint>?client_
    id=<clientid>&scope=<scopes>&response_type=token";
  string endURL = "http://<appendpoint>";
  System.Uri startURI = new System.Uri(
    "https://<providerendpoint>?client_
    id=<clientid>&scope=<scopes>&response_type=token");
  System.Uri endURI = new System.Uri(
    "http://<appendpoint>");
  string result;
  try
  {
    var webAuthenticationResult =
      await WebAuthenticationBroker.AuthenticateAsync(
      WebAuthenticationOptions.None,
      startURI,
      endURI);
    switch (webAuthenticationResult.ResponseStatus)
    {
      case WebAuthenticationStatus.Success:
        result = webAuthenticationResult.ResponseData.ToString();
        break;
      case WebAuthenticationStatus.ErrorHttp:
        result = 
          webAuthenticationResult.ResponseErrorDetail.ToString();
        break;
      default:
        result = webAuthenticationResult.ResponseData.ToString();
        break;
    }
  }
  catch (Exception ex)
  {
    result = ex.Message;
  }
  return result;
}

スマート カード認証

マイクロソフトは、自社ネットワークへの VPN 接続を認証する手段や、自社ビルおよびその他の企業リソースへのセキュアなアクセスを提供する手段として、長年スマート カードを使用してきました。現在では、スマートカードは簡単に独自ソフトウェアに組み込めるようになっています。Windows.Devices.SmartCards 名前空間に含まれている SmartCard、SmartCardConnection などのクラスを使用すると、スマート カードを認証および管理するためのコードを記述できます。スマート カードは非常に複雑だと思われることがありますが、実際はそうではありません。たとえば、カード リーダーに現在挿入されているカードの種類を検証する場合は、次のようなコードを記述できます。

string selector = SmartCardReader.GetDeviceSelector();
DeviceInformationCollection devices = 
  await DeviceInformation.FindAllAsync(selector);
foreach (DeviceInformation device in devices)
{
  SmartCardReader reader =
    await SmartCardReader.FromIdAsync(device.Id);
  IReadOnlyList<SmartCard> cards = await reader.FindAllCardsAsync();
}

Windows.Devices.DeviceInformation で各デバイスの情報を取得していることに注意してください。Windows の場合は、これがハードウェアをクエリする標準的な方法です。Windows ランタイムでは、.NET 開発者が以前は利用できなかった、ハードウェアとの通信用オブジェクトの多くが公開されています。

生体認証

多くのデバイスやコンピューターでは生体認証用ハードウェアがサポートされていないので、ユーザー名とパスワードによる標準的な認証手法以外に別の認証形式を使用できる可能性は高くありません。それでも、保存および登録済みの指紋を使用してソフトウェアを読み取ることはできます。これは、アクセシビリティのニーズを抱えるユーザーにとってすばらしい機能であり、きわめて便利です。

Lenovo Carbon Touch X1 ノート PC の場合を考えてみましょう。このモデルには、キーボード付近に指紋読み取り装置が組み込まれています。Windows 8 生体認証を利用すると、指紋認証を使用できます。図 5 に、生体認証に使用するコードを示します。

図 5 指紋認証

var availability = 
  await UserConsentVerifier.CheckAvailabilityAsync();
if (UserConsentVerifierAvailability.Available) {
  var consentResult = 
  await UserConsentVerifier.RequestVerificationAsync(userMessage);
}
var consentResult = 
  await UserConsentVerifier.RequestVerificationAsync(userMessage);
switch (consentResult)
{
  case UserConsentVerificationResult.Verified:
    returnMessage = "Fingerprint verified.";
    break;
  case UserConsentVerificationResult.DeviceBusy:
    returnMessage = "Biometric device is busy.";
    break;
  case UserConsentVerificationResult.DeviceNotPresent:
    returnMessage = "No biometric device found.";
    break;
  case UserConsentVerificationResult.NotConfiguredForUser:
    returnMessage = "The user has no fingerprints registered.";
    break;
  case UserConsentVerificationResult.RetriesExhausted:
    returnMessage = "Too many failed attempts.";
    break;
  case UserConsentVerificationResult.Canceled:
    returnMessage = "Fingerprint authentication canceled.";
    break;
  default:
    returnMessage = "Fingerprint authentication is currently unavailable.";
    break;
}

図 5 のコードは、図 2 とほぼ同じモーダル ダイアログを表示します。ただし、CheckAvailabilityAsync の呼び出し中に、生体認証デバイスでの指紋のスキャンに同意を求めるメッセージを表示します。ユーザーが指紋をスキャンしたら、この同意結果をクエリして、検証可能なスキャンかどうかを確認できます。

サインアウト

Microsoft アカウントを使用すると、Windows 8 にシームレスに統合したリッチで一貫性のあるエクスペリエンスを提供できます。現在ではさまざまな認証プロバイダーを利用できるので、独自の認証プロバイダーを作成する前に、既存の認証プロバイダーを使用することをお勧めします。Twitter、Facebook、マイクロソフトといった認証プロバイダーのうちどれを使用する場合でも、各プロバイダーによって、ユーザーの個人情報の安全な管理に関する課題や問題に対して既に対策が取られています。また、このようなプロバイダーでは、セキュリティも最新に保たれています。このため、定評のあるサードパーティ製検証は、最新のアプリの認証に最適です。

どうしても必要な場合を除き、ユーザーの個人情報を保存する独自のアルゴリズムは作成しないでください。ユーザーの個人情報を保持する必要がある場合は、資格情報保管ボックスなどのサービスを使用してください。資格情報保管ボックスを使用すると、ユーザーの資格情報を安全に保持できます。この結果、クラウド上の保管場所に資格情報が保持され、ローミングが可能になるので、ユーザーが複数のアプリ セッションにまたがって自動でサインインする手段をアプリで使用できます。

アプリを複数のデバイス (タブレット、携帯電話など) で実行する場合、ローミングは必須機能です。資格情報保管ボックスを使用すると、資格情報を安全にロックダウンしながら、アプリのバージョン間、ソーシャル ネットワーク間、または他の外部サイト間で資格情報を渡すことができます。さらに、ユーザー情報を保存するためのインフラストラクチャを維持する必要がなくなります。資格情報保管ボックスの詳細については、bit.ly/1qFxfmG (英語) を参照してください。

生体認証のような拡張認証をアプリに実装すれば、ストアで最高級の評価を受けるアプリが完成します。このようなアプリの UI は、最新で使いやすく、あらゆる機能が備わっています。ただし、まったく同じ認証用周辺機器がすべてのデバイスに搭載されているわけではないので、生体認証のような認証を唯一の認証方法として利用しないでください。

Rachel Appel は 20 年を超える IT 業界での経験を持つマイクロソフトの元社員で、コンサルティング、執筆活動、および指導を行っています。彼女は Visual Studio Live!、DevConnections、MIX など、業界トップ クラスのカンファレンスで講演しています。専門分野は、マイクロソフトの各種開発ツールやオープン Web を重視したテクノロジとビジネスを連携させるソリューションの開発です。彼女のことをもっと知りたい方は、彼女の Web サイト rachelappel.com (英語) をご覧ください。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Frank La Vigne に心より感謝いたします。