App Service Authentication/Authorization の機能強化

このポストは、11 月 16 日に投稿された Expanding App Service Authentication/Authorization の翻訳です。

去年の今ごろですが、私の同僚である Byron Tardif (英語) が、Azure Websites Authentication/Authorization の紹介記事を公開しました。この機能の登場によって、Azure Active Directory を使ってわずか数クリックでサイトを保護することが可能になりました。その使いやすさについてはたくさんの反響をいただきましたが、同時に多くのお客様から、特に API を利用する際の柔軟性に乏しいという声も寄せられていました。

その後 3 月になり、Web Apps、Mobile Apps、API Apps、Logic Apps という機能を 1 つのプラットフォームにまとめたサービス Azure App Service が発表されました。この Azure App Service に含まれる App Service ゲートウェイにより、サイト間での認証の共有と Mobile Services のログイン サポートの拡張が実現しましたが、認証に関する柔軟性を個々のアプリケーション レベルでさらに高めてほしいという要望は根強く残されていました。

本日マイクロソフトは、これまでのアプローチを融合し、App Service の Authentication/Authorization 機能を拡張したことを発表いたします。新しい ID プロバイダー、新しいサインイン オプションに対応し、アクセス制御の柔軟性もさらに向上しました。これによりユーザーは、ゲートウェイが提供する豊富な機能すべてをサイト単位で利用し、これらを快適な操作性で管理できるようになりました。この機能は、Web アプリケーションやモバイル アプリケーションの場合に App Service ゲートウェイに代わりマイクロソフトが推奨する機能となります。

 

使用を開始する

App Service Authentication/Authorization は Azure 管理ポータル プレビューから利用できます。有効化するには、任意の Web またはモバイル アプリの [Settings] ブレードに移動して [Authentication/Authorization] を選択します。スイッチを [On] に切り替えるとサイト保護オプションが表示されます。

 

大きな変更点の 1 つが、プロバイダーの選択肢が広がって Azure Active Directory だけでなく Facebook、Google、Microsoft アカウント、Twitter を選択できるようになったことです。いずれかを選択し構成設定で有効化することにより、ユーザーがそのプロバイダーでログインできるようになります。[Facebook] ブレードと [Microsoft Account] ブレードには、オプションのスコープの一覧が表示されます。このスコープをログイン時に要求することで、ユーザーに関する追加情報を取得することができます。

 

 

AAD には複数のモードが提供されています。数クリックで構成できる [Express] オプションの使用を選択したり、必要な場合は [Advanced] オプションを使って AAD の構成を手動で指定できます。各プロバイダーの詳しい構成方法については、Azure Active Directory、Facebook、Google、Microsoft アカウント、Twitter それぞれのトピックをお読みください。

 

段階的な認証

多くのアプリケーションは、アプリケーションのさまざまな領域ごとに異なるアクセス制限を適用しています。API についても、公開できるものもあればサインインを要求すべきものもあります。以前の Authentication/Authorization 機能では、サイト全体でログインを要求することにより、このようなアクセス制限を一律に適用することしかできませんでした。マイクロソフトでは、このオプションも引き続き提供すると共に、アクセスの判断をアプリケーション コードで実装できるようにしました。現在この実装が最も容易なのは ASP.NET サイトです。ASP.NET サイトでは、認証済みのユーザー情報に ThreadPrincipal が設定され、アプリケーションが保護対象のすべての操作に Authorize 属性を使用し、それ以外の操作は許可されます。その他のプラットフォームを使用しているアプリケーションは、サイトを完全に保護するオプションを使用するか、Cookie またはトークンを手動で検証することができます。

Authentication/Authorization を有効化すると、アクセスの決定は既定でアプリケーション コードに委ねられます。認証されなかったトラフィックをサイトから特定のプロバイダーに転送するには、[Action to take when request is not authenticated] ドロップダウンでプロバイダーを選択します。

 

一度に複数の ID プロバイダーを選択できますが、完全なサイト保護で構成できるのは 1 つのプロバイダーだけです。複数のプロバイダーを使用するアプリケーションの多くで、認証されていない要求に対して [No action] オプションを使用することが推奨されます。このオプションでは、ユーザーがサインインするタイミングと方法をアプリケーションが決定できます。

 

サインイン オプション

これまでの Authentication/Authorization では、認証されていない要求がサイトに実行された場合は、ブラウザーのリダイレクトによるログインだけが許可されていました。現在は、この動作を使用するか、ログイン フローを明示的に開始するかを開発者が選択できるようになりました。

アプリケーションは、サイトの /.auth/login/<provider> エンドポイントにユーザーを転送することで、以前と同様のリダイレクトをアプリケーション自身で実行することができます。 <provider> は、aad、facebook、google、microsoftaccount、twitter のいずれかになります。ログイン ボタンが表示されるサイトやモバイル アプリケーションの多くは、このオプションが最適です。

もう 1 つの方法は、プロバイダーの SDK を使ってクライアントがトークンを取得し、セッション トークンと交換する方法です。これには、JSON 本文の "access_token" (Microsoft アカウントの場合 "authenticationToken") キーの下にプロバイダー トークンを指定し、同じエンドポイントに HTTP POST を送信します。これは、使用しているプラットフォーム用にプロバイダーの SDK が提供されているモバイル アプリケーションに推奨されるソリューションです。その他、多くの Web アプリケーションや API アプリケーションでも利用できます。

このサポートは、App Service がヘッドレス認証をサポートするようになったということを意味します。デーモン プロセスや、インターフェイスを使用しない API アクセスを必要とするその他のクライアントがある場合、ADD サービス プリンシパルを使用してトークンを要求し、このトークンをアプリケーションでの認証に使用することができます。ADD の場合はさらに、ベアラー トークンの仕様に従って、セッション トークンを省略し ADD トークンだけを Authorization ヘッダーに含めることが許可されます。

本日の発表で実現された更新により、Mobile Apps クライアント SDK が LoginAsync() メソッドで上記フローの両方をサポートするようになりました。

 

トークン ストア

トークン ストアの有効化/無効化の切り替えも、注目したいポータル オプションの 1 つです。この機能により、利用するプロバイダーのトークンをアプリケーションに格納し、関連付けられたユーザーのコンテキストでのみアクセスを許可することが可能になります。現在このオプションは既定で有効化され、モバイル シナリオの場合は必須となります。

追加のユーザー情報や Graph の呼び出しに必要なすべてのトークンを取得するには、サイトの /.auth/me エンドポイントに GET を送信します。有効なセッション Cookie またはセッション トークンが要求に含まれていれば、現在のユーザー情報が返されます。この API は、Mobile Apps サーバー SDK が提供する GetAppServiceIdentityAsync() メソッドを使って簡単に利用できます。

 

強化された認証機能をご活用ください

今回の機能強化により、App Service アプリケーションの認証に必要なすべての機能が揃ったことになります。現在、新しい機能や API に関するドキュメントの作成に取り組んでいます。また、追加の機能強化などもブログで紹介する予定ですので、引き続きご注目ください。

App Service Authentication/Authorization をお試しいただき、ご感想をお寄せいただけますと幸いです。チームにご意見をお送りいただく際は、Azure のフィードバック用サイト (英語)、MSDN フォーラム、本ブログ記事のコメント欄をお使いください。