アプリ認証を構成する
このドキュメントでは、環境でのアプリ認証の構成について説明しています。また、Cookieに関する説明など、認証メカニズムに関する情報も示します。
アプリ認証の設定を構成する
Single sign-on between app types（SSO）の設定は、Platform Server 11.8以降で使用できます。
OutSystemsの認証メカニズムは、様々なセキュリティ要件を満たせるよう、環境ごとに構成することができます。
全体的な認証を設定し、さらに永続的な認証とセッション認証に固有の設定を構成することもできます。
以下の設定は、永続的な認証とセッション認証の両方に適用されます。
-
Cache Time In Minutes – デバイスが送信した認証情報をサーバーが有効とみなし、データベースから取得しない分単位の時間。この時間を過ぎると、サーバーは認証トークンをデータベースに保存されている情報と照らし合わせて検証し、新しい認証トークンを提供します。0に設定した場合、認証キャッシュメカニズムは無効になります。
-
Single Sign-On Between App Types – このオプションを有効にすると、ユーザーがサインインを再度行わずに、プログレッシブWebアプリとして配布された従来のWebアプリ、リアクティブWebアプリ、モバイルアプリを移動することができます。たとえば、ユーザーが従来のWebアプリにサインインしているときにリアクティブWebアプリに移動する場合、リアクティブWebアプリへのサインインが自動的に行われます。Single Sign-On Between App Typesの設定を有効にするには、環境でHTTPSを有効にしておく必要があります。
［Single Sign-On Between App Types］は、デフォルトでは有効になっていません。有効にするには、以下の説明をご覧ください。
以下の設定は、永続的な認証に使用します。
-
Max Idle Time – サーバーと通信することなく、ユーザーがサーバーへのログインを継続できる最大の日数。この日数を過ぎると、アプリケーションをオンラインにした（サーバーに接続した）際に、ユーザーは再度ログインする必要があります。
-
Cookie Expiration – サーバーと通信することなく、ユーザーがアプリケーションへのログインを継続できる最大の日数。この日数を過ぎるとCookieが期限切れになり、アプリケーションをオンラインにした（サーバーに接続した）際に、ユーザーは再度ログインする必要があります。
以下の設定は、セッション認証に使用されます。
- Max Idle Time – サーバーがユーザー認証を有効と認識するサーバーコール間の分単位の時間。
OutSystems環境でアプリの認証設定を構成するには、以下の手順を実行します。
-
OutSystems環境のService Center管理コンソールに移動します。
-
［Administration］セクションに移動して、［Security］タブを選択します。
-
［Applications Authentication］領域を選択します。
このページでは、Cookieの値を認証して暗号化するための新しいキーを生成することもできます。これを実行した場合、アプリの全ユーザーが次のサーバーリクエスト時に再度ログインする必要が出てきます。新しいキーを生成するには、［Authentication and Encryption Keys］領域の［Generate］ボタンを押します。
認証タイプ
サーバーは、認証タイプに従って認証Cookieを取り扱います。認証には2種類あります。
- セッション認証 – エンドユーザーがアプリを終了すると認証Cookieが破棄されます。
- 永続的な認証 – アプリケーションを何回起動しても認証Cookieが維持されます。
開発者は、ユーザーをログインさせるためのUser_Loginアクションを呼び出す際に、RememberLoginパラメータで認証タイプを指定します。
認証Cookie
エンドユーザーがログインすると、サーバーは2つの認証Cookieをアプリに送ります。これらのCookieにより、これに続くサーバーリクエストでエンドユーザーが認証されます。このセクションでは、OutSystemsアプリの認証メカニズムで使用される2種類のCookieについて説明します。
Cookie nr1<User Provider Name>:
- サーバーはこのCookieを、必要に応じて、セッションを強制的に終了させるために使用します。
- セッション認証に必要な情報を含みます。
- HttpOnlyフラグはtrueに設定され、JavaScriptでCookieにアクセスできません。
Cookie nr2<User Provider Name>:
- ビルトイン関数であるGetUserIdを使用し、ユーザー識別子に関する情報をアプリケーションコードに提供します。
- CSRF攻撃を避けるために必要な情報を保持しています。
- HttpOnlyフラグはfalseに設定され、JavaScriptでCookieにアクセスできます。nr2 CookieのHttpOnlyフラグをtrueに変更しないでください。アプリが予期しない動作をする可能性があります。
認証Cookieを検証する
サーバー呼び出しの実行時に、アプリはX-CSRF-TokenリクエストヘッダーにCSRFトークンを持つ認証Cookieをサーバーに送ります。
サーバーは、以下の条件を確認してリクエストを検証します。
- リクエストにX-CSRF-Tokenヘッダーが含まれていること。
- リクエストに2つの認証Cookieが含まれていること。
- Cookieの情報が本物であり、偽造されていないこと。
- ログイン有効期間が残っていること。
すべての条件を満たす場合、サーバーはCookieで識別されたユーザーからのものとしてリクエストを認証します。そうでない場合、匿名のユーザーからのものとして処理します。
認証キャッシュ
アプリの認証メカニズムは、リクエストの際に毎回データベースの認証情報を検証し更新するという負荷を避けるため、キャッシュ機能を持っています。
一定の期間、サーバーは認証済みセッションからのリクエスト認証にあたり、データベースから認証情報を取得するのではなく、Cookieに保存された情報を使用します。
アプリケーションからログアウトする
エンドユーザーがアプリケーションからログアウトすると、すべてのセッションがターミネートされます。これにより、無効な認証済みの永続的セッションが存続しないようにします。
アプリケーションにキャッシュが有効になっている要素（Cache in Minutesプロパティを使用）が含まれている場合、キャッシュが無効になるまでの短い期間、キャッシュ済みのコンテンツが引き続き表示されることがあります。その期間が過ぎた後、認証情報は無効になるため、データベースから再取得する必要があります。