PHP でのユーザーの認証

App Engine などの Google Cloud マネージドプラットフォーム上で実行するアプリは、Identity-Aware Proxy（IAP）を使用することにより、ユーザー認証やセッション管理の手間を省いてアプリへのアクセスを制御できます。IAP は、アプリへのアクセスを制御できるだけでなく、新しい HTTP ヘッダーの形式でメールアドレスや永続的な識別子などの認証済みユーザーに関する情報をアプリに提供することもできます。

目標

IAP を使用することにより、App Engine アプリのユーザーに自分自身を認証するように要求する。
アプリでユーザーの ID にアクセスして、現在のユーザーの認証済みメールアドレスを表示する。

料金

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud CLI をインストールします。

gcloud CLI を初期化するには:

gcloud init

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud CLI をインストールします。

gcloud CLI を初期化するには:

gcloud init

背景

このチュートリアルでは、IAP を使用してユーザーを認証します。これは、いくつかのアプローチのうちの 1 つにすぎません。ユーザーのさまざまな認証方法の詳細については、認証のコンセプトセクションをご覧ください。

Hello `user-email-address` アプリ

このチュートリアル用のアプリは、最小の Hello world App Engine アプリで、「Hello world」の代わりに「Hello user-email-address」を表示する特別な機能を備えています。ここで、user-email-address は認証済みユーザーのメールアドレスです。

この機能は、IAP がアプリに渡す各ウェブリクエストに追加する認証情報を調べることで可能になります。アプリに届くリクエストには 3 つの新しいリクエストヘッダーが追加されます。最初の 2 つのヘッダーは、ユーザーの識別に使用できる書式なしテキスト文字列です。3 つ目のヘッダーは、同じ情報を含む暗号署名付きオブジェクトです。

X-Goog-Authenticated-User-Email: ユーザーのメールアドレスでユーザーが識別されます。アプリで回避できる場合は、個人情報を保存しないようにしてください。このアプリはデータを保存しません。ユーザーにエコーバックするだけです。
X-Goog-Authenticated-User-Id: Google が割り当てたこのユーザー ID は、ユーザーに関する情報は表示しませんが、ログインしているユーザーが過去に表示されたユーザーと同じであることをアプリが認識できるようにします。
X-Goog-Iap-Jwt-Assertion: インターネットウェブリクエスト以外に、IAP を迂回してきた他のクラウドアプリからのウェブリクエストを受け入れるように Google Cloud アプリを構成できます。アプリがこのように構成されている場合は、このようなリクエストのヘッダーが偽造されている可能性があります。上記のいずれかの書式なしテキストヘッダーを使用する代わりに、この暗号署名付きヘッダーを使用して、情報が Google から提供されたものであることを確認できます。ユーザーのメールアドレスと永続的なユーザー ID の両方をこの署名付きヘッダーの一部として使用できます。

アプリが、インターネットウェブリクエストのみを受け入れ、アプリに対する IAP サービスを無効にできないように構成されている場合は、一意のユーザー ID を取得するコードは 1 行で済みます。

$userId = getallheaders()['X-Goog-Authenticated-User-Id'] ?? null;

ただし、耐障害性が求められるアプリでは、予期せぬ構成や環境の問題などの障害を想定しておく必要があるため、代わりに、暗号署名付きヘッダーの使用と確認を行う関数を作成することをおすすめします。ヘッダーの署名は偽造できないため、検証時に、識別を返すのに使用できます。

ソースコードを作成する

テキストエディタを使用して、index.php という名前のファイルを作成し、次のコードを貼り付けます。

authenticate-users/index.php

GitHub で表示

require_once __DIR__ . '/vendor/autoload.php';

/**
 * Checks that the JWT assertion is valid (properly signed, for the
 * correct audience) and if so, returns strings for the requesting user's
 * email and a persistent user ID. If not valid, returns null for each field.
 *
 * @param string $idToken The JWT string to assert.
 * @param string $audience The audience of the JWT.
 *
 * @return string[] array containing [$email, $id]
 * @throws Exception on failed validation
 */
function validate_assertion(string $idToken, string $audience) : array
{
    $auth = new Google\Auth\AccessToken();
    $info = $auth->verify($idToken, [
      'certsLocation' => Google\Auth\AccessToken::IAP_CERT_URL,
      'throwException' => true,
    ]);

    if ($audience != $info['aud'] ?? '') {
        throw new Exception(sprintf(
            'Audience %s did not match expected %s', $info['aud'], $audience
        ));
    }

    return [$info['email'], $info['sub']];
}

/**
 * This is an example of a front controller for a flat file PHP site. Using a
 * static list provides security against URL injection by default.
 */
switch (@parse_url($_SERVER['REQUEST_URI'])['path']) {
    case '/':
        if (!Google\Auth\Credentials\GCECredentials::onGce()) {
            throw new Exception('You must deploy to appengine to run this sample');
        }
        $metadata = new Google\Cloud\Core\Compute\Metadata();
        $audience = sprintf(
            '/projects/%s/apps/%s',
            $metadata->getNumericProjectId(),
            $metadata->getProjectId()
        );
        $idToken = getallheaders()['X-Goog-Iap-Jwt-Assertion'] ?? '';
        try {
            list($email, $id) = validate_assertion($idToken, $audience);
            printf("<h1>Hello %s</h1>", $email);
        } catch (Exception $e) {
            printf('Failed to validate assertion: %s', $e->getMessage());
        }
        break;
    case '': break; // Nothing to do, we're running our tests
    default:
        http_response_code(404);
        exit('Not Found');
}

この index.php ファイルの詳細については、このチュートリアルの後半のコードについてセクションで説明します。

composer.json という名前の別のファイルを作成し、次のコードを貼り付けます。

authenticate-users/composer.json

GitHub で表示
```
{
  "require": {
    "php": ">=7.1",
    "google/auth": "^1.9",
    "google/cloud-core": "^1.32",
    "kelvinmo/simplejwt": "^0.4.0"
  }
}
```
composer.json ファイルでは、App Engine で読み込む必要のある PHP ライブラリが一覧表示されます。
- firebase/php-jwt は、JWT のチェックおよびデコード機能を提供します。
- guzzle/http は、ウェブサイトからデータを取得するための HTTP クライアントです。
app.yaml という名前のファイルを作成し、次のテキストを入力します。

authenticate-users/app.yaml

GitHub で表示
```
runtime: php73
```
app.yaml ファイルは、コードが必要とする言語環境を App Engine に指示します。

コードの説明

このセクションでは、index.php 内のコードの機能について説明します。アプリを実行するだけの場合は、アプリのデプロイセクションまでスキップできます。

次のコードが index.php ファイルに格納されています。ホームページへの HTTP GET リクエストがアプリによって受信された場合は、/ のスイッチケースが呼び出されます。

authenticate-users/index.php

GitHub で表示

/**
 * This is an example of a front controller for a flat file PHP site. Using a
 * static list provides security against URL injection by default.
 */
switch (@parse_url($_SERVER['REQUEST_URI'])['path']) {
    case '/':
        if (!Google\Auth\Credentials\GCECredentials::onGce()) {
            throw new Exception('You must deploy to appengine to run this sample');
        }
        $metadata = new Google\Cloud\Core\Compute\Metadata();
        $audience = sprintf(
            '/projects/%s/apps/%s',
            $metadata->getNumericProjectId(),
            $metadata->getProjectId()
        );
        $idToken = getallheaders()['X-Goog-Iap-Jwt-Assertion'] ?? '';
        try {
            list($email, $id) = validate_assertion($idToken, $audience);
            printf("<h1>Hello %s</h1>", $email);
        } catch (Exception $e) {
            printf('Failed to validate assertion: %s', $e->getMessage());
        }
        break;
    case '': break; // Nothing to do, we're running our tests
    default:
        http_response_code(404);
        exit('Not Found');
}

スイッチステートメントは、IAP が受信リクエストから追加した JWT アサーションヘッダー値を取得し、その暗号署名付き値を検証する関数を呼び出します。返される最初の値（メール）は、作成されて返される最小ウェブページで使用されます。

authenticate-users/index.php

GitHub で表示

/**
 * Checks that the JWT assertion is valid (properly signed, for the
 * correct audience) and if so, returns strings for the requesting user's
 * email and a persistent user ID. If not valid, returns null for each field.
 *
 * @param string $idToken The JWT string to assert.
 * @param string $audience The audience of the JWT.
 *
 * @return string[] array containing [$email, $id]
 * @throws Exception on failed validation
 */
function validate_assertion(string $idToken, string $audience) : array
{
    $auth = new Google\Auth\AccessToken();
    $info = $auth->verify($idToken, [
      'certsLocation' => Google\Auth\AccessToken::IAP_CERT_URL,
      'throwException' => true,
    ]);

    if ($audience != $info['aud'] ?? '') {
        throw new Exception(sprintf(
            'Audience %s did not match expected %s', $info['aud'], $audience
        ));
    }

    return [$info['email'], $info['sub']];
}

validate_assertion 関数は、google/auth ライブラリを使用して、アサーションが適切に署名されていることを確認し、アサーションからペイロード情報を抽出します。アサーションをデコードできない場合は、この関数は例外をスローします。成功すると、この関数は認証済みユーザーのメールアドレスと永続的な一意の ID を返します。

JWT アサーションを検証するには、アサーションに署名した機関（この場合は Google）の公開鍵証明書と、アサーションの対象オーディエンスを把握している必要があります。App Engine アプリの場合、オーディエンスは Google Cloud のプロジェクト識別情報を含む文字列です。この関数は、それらの証明書とその前の関数からのオーディエンス文字列を取得します。

authenticate-users/index.php

GitHub で表示

$metadata = new Google\Cloud\Core\Compute\Metadata();
$audience = sprintf(
    '/projects/%s/apps/%s',
    $metadata->getNumericProjectId(),
    $metadata->getProjectId()
);

自分で Google Cloud プロジェクトの数値 ID と名前を検索して、ソースコードに含めることもできますが、代わりに、audience 関数がすべての App Engine アプリで使用可能になっている標準のメタデータサービスを照会することによってこの処理を行います。

App Engine のメタデータサービス（および他の Google Cloud コンピューティングサービス用の類似のメタデータサービス）は、外観がウェブサイトに似ており、標準のウェブクエリによって照会されます。ただし、実際には、外部サイトではなく、実行中のアプリに関する要求された情報を返す内部機能であるため、https リクエストの代わりに http リクエストを使用しても安全です。これは、JWT アサーションの対象オーディエンスを定義するために必要な現在の Google Cloud 識別子を取得するために使用されます。

アプリのデプロイ

これで、アプリをデプロイして、次いで Cloud IAP でユーザーが認証しないとユーザーがアプリにアクセスできないようにできます。

ターミナルウィンドウで、app.yaml ファイルが格納されたディレクトリに移動して、アプリを App Engine にデプロイします。
```
gcloud app deploy
```
プロンプトが表示されたら、最寄のリージョンを選択します。
デプロイ操作を続行するかどうかを尋ねられたら、Y と入力します。

数分以内に、アプリがインターネット上に公開されます。
次のようにしてアプリを表示します。
```
gcloud app browse
```
出力で、web-site-url（アプリのウェブアドレス）をコピーします。
ブラウザウィンドウで、web-site-url を貼り付けてアプリを開きます。

IAP をまだ使用していないのでメールが表示されないため、ユーザー情報がアプリに送信されません。

IAP を有効にする

これで App Engine インスタンスが存在するようになり、IAP を使用して保護できます。

Google Cloud Console で、[Identity-Aware Proxy] ページに移動します。

Identity-Aware Proxy ページに移動
今回はこのプロジェクト用の認証オプションを初めて有効にしたため、IAP を使用するには OAuth 同意画面を構成する必要があることを示すメッセージが表示されます。

[同意画面を構成] をクリックします。
[認証情報] ページの [OAuth 同意画面] タブで、次のフィールドに値を入力します。
- アカウントが Google Workspace の組織にある場合は、[外部] を選択して [作成] をクリックします。開始すると、アプリは明示的に許可されたユーザーのみが利用できます。
- [アプリケーション名] フィールドに、IAP Example と入力します。
- [サポートメール] フィールドに、メールアドレスを入力します。
- [承認済みドメイン] フィールドに、アプリの URL のホスト名部分（iap-example-999999.uc.r.appspot.com など）を入力します。フィールドにホスト名を入力したら、Enter キーを押します。
- [アプリケーションホームページリンク] フィールドに、アプリの URL（https://iap-example-999999.uc.r.appspot.com/ など）を入力します。
- [Application privacy policy line] フィールドでは、テスト用にホームページリンクと同じ URL を使用します。
[保存] をクリックします。認証情報の作成が要求されたら、ウィンドウを閉じます。
Google Cloud コンソールで、[Identity-Aware Proxy] ページに移動します。

Identity-Aware Proxy ページに移動
ページを更新するには、[Refresh]（更新）をクリックします。ページに、保護可能なリソースのリストが表示されます。
[IAP] 列でクリックしてアプリの IAP をオンにします。
ブラウザで、再度 web-site-url にアクセスします。
ウェブページの代わりに、自分を認証するためのログイン画面が表示されます。ログインしようとすると、アプリにアクセス可能なユーザーのリストが IAP にないため、アクセスが拒否されます。

アプリに承認済みユーザーを追加する

Google Cloud コンソールで、[Identity-Aware Proxy] ページに移動します。

Identity-Aware Proxy ページに移動
App Engine アプリのチェックボックスをオンにしてから、[プリンシパルを追加] をクリックします。
allAuthenticatedUsers と入力してから、[Cloud IAP/IAP で保護されたウェブアプリユーザー] 役割を選択します。
[保存] をクリックします。

これで、Google で認証可能なすべてのユーザーがアプリにアクセスできます。必要に応じて、1 人または複数のユーザーやグループをプリンシパルとして追加するだけで、さらにアクセスを制限できます。

Gmail または Google Workspace のメールアドレス
Google グループメールアドレス
Google Workspaceのドメイン名

アプリにアクセスする

ブラウザで、web-site-url にアクセスします。
ページを更新するには、[更新] 更新をクリックします。
ログイン画面で、Google 認証情報を使用してログインします。

ページに、メールアドレスが記載された「Hello user-email-address」ページが表示されます。

以前と同じページが表示される場合は、IAP を有効にしたブラウザで新しいリクエストが完全に更新されない問題が発生している可能性があります。すべてのブラウザウィンドウを閉じてから、もう一度開いて、やり直してください。

認証のコンセプト

アプリが、そのユーザーを認証し、承認されたユーザーのみにアクセスを制限可能な方法がいくつかあります。次のセクションで、一般的な認証方法をアプリの負荷が高い順に一覧表示します。

オプション	メリット	デメリット
アプリ認証	インターネット接続の有無にかかわらず、どのプラットフォームでもアプリを実行できる他のサービスを使用して認証を管理する必要がない	アプリはユーザー認証情報を安全に管理して、漏洩しないよう保護する必要があるアプリはログインしているユーザーのセッションデータを維持する必要があるアプリはユーザー登録、パスワード変更、パスワード復元を提供する必要がある
OAuth2	デベロッパーワークステーションなど、インターネットに接続されたあらゆるプラットフォームでアプリを実行できるアプリはユーザー登録、パスワード変更、パスワード復元の各機能を必要としないユーザー情報漏洩のリスクが他のサービスに委任される新しいログインセキュリティ対策がアプリの外部で処理される	ユーザーが ID サービスに登録する必要があるアプリはログインしているユーザーのセッションデータを維持する必要がある
IAP	アプリはユーザー、認証、セッション状態を管理するためのコードを必要としないアプリは侵害される可能性のあるユーザー認証情報を持たない	アプリはサービスでサポートされているプラットフォームでしか実行できない。具体的には、App Engine などの IAP をサポートする特定の Google Cloud サービスです。

アプリ管理認証

この方法では、アプリがユーザー認証のすべての側面を独自に管理します。アプリは、ユーザー認証情報の独自のデータベースを維持してユーザーセッションを管理し、ユーザーアカウントとパスワードの管理、ユーザー認証情報のチェック、認証されたログインごとのユーザーセッションの発行、チェック、更新を行う必要があります。次の図は、アプリ管理認証方法を示しています。

アプリケーション管理フロー

図に示すように、ユーザーがログインすると、アプリがそのユーザーのセッションに関する情報を作成して維持します。ユーザーがアプリにリクエストを発行する場合は、そのリクエストにアプリが検証するセッション情報が含まれている必要があります。

このアプローチの主なメリットは、自己完結型であることと、アプリの制御下で行われることです。アプリをインターネット上で使用可能にする必要さえありません。主なデメリットは、アプリがすべてのアカウント管理機能を提供し、すべての機密性の高い認証情報データを保護する必要があることです。

OAuth2 を使用した外部認証

アプリ内ですべてを処理する代わりに、Google などの外部の ID サービスを使用して、すべてのアカウント情報と機能を処理し、機密性の高い認証情報を保護することをおすすめします。ユーザーがアプリにログインしようとすると、リクエストが ID サービスにリダイレクトされ、そこでユーザーが認証されてから、必要な認証情報と一緒にリクエストがアプリに返されます。詳しくは、Using OAuth 2.0 for Web Server Applications（英語）をご覧ください。

次の図は、OAuth2 方式を使用した外部認証を示しています。

OAuth2 のフロー

図のフローは、ユーザーがアプリにアクセスするためのリクエストを送信するところから始まります。直接応答する代わりに、アプリは、ユーザーのブラウザを Google の Identity Platform にリダイレクトします。そこで、Google にログインするためのページが表示されます。ログインに成功すると、ユーザーのブラウザがアプリに戻されます。このリクエストには、認証されたユーザーに関してアプリが検索可能な情報が含まれており、アプリはユーザーに応答できます。

この方法には、アプリにとっての多くのメリットがあります。アプリがすべてのアカウント管理機能とリスクを外部サービスに委任することで、アプリを変更せずにログインとアカウントセキュリティを向上させることができます。ただし、上の図に示すように、この方法を使用するには、アプリからインターネットにアクセスできる必要があります。また、アプリには、ユーザーの認証後にセッションを管理する責任があります。

Identity-Aware Proxy

このチュートリアルで扱う 3 つ目のアプローチは、IAP を使用して、認証とアプリに対するなんらかの変更を伴うセッション管理をすべて処理する方法です。IAP は、アプリへのすべてのウェブリクエストを傍受して、認証されていないリクエストをブロックし、それ以外のリクエストはリクエストごとにユーザー ID データを追加してアプリに渡します。

リクエストの処理を次の図に示します。

IAP のフロー

ユーザーからの要求は、IAP によって傍受され、認証されていない要求がブロックされます。認証されたユーザーが許可されたユーザーのリストに含まれている場合は、認証されたリクエストがアプリに渡されます。IAP を介して渡されたリクエストには、要求を行ったユーザーを識別するヘッダーが追加されます。

アプリは、ユーザーアカウントやセッション情報を処理する必要がなくなります。ユーザーの一意の識別子を知る必要があるオペレーションでは、受信ウェブリクエストから直接取得できます。ただし、App Engine やロードバランサなど、IAP をサポートするコンピューティングサービスでのみ使用できます。ローカル開発マシンで IAP を使用することはできません。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

注意

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

Google Cloud コンソールで、[リソースの管理] ページに移動します。
[リソースの管理] に移動
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

PHP でのユーザーの認証

目標

料金

始める前に

背景

Hello user-email-address アプリ

ソースコードを作成する

コードの説明

アプリのデプロイ

IAP を有効にする

アプリに承認済みユーザーを追加する

アプリにアクセスする

認証のコンセプト

アプリ管理認証

OAuth2 を使用した外部認証

Identity-Aware Proxy

クリーンアップ

次のステップ

Hello `user-email-address` アプリ