🌐
第四回：GCPでログイン機能を作ってみた
公開
2025-01-08
文章量
約6275字
さかもも
目次
はじめに
ログイン認証をどうやって実現したか
Identity Platformとは？
Identity Aware Proxyとは？
認証関連について構築した構成図
インフラの構成手順
1. Cloud Runの構築（バックエンド側）
2. Identity Platformの設定（初期化）
3. Identity Aware Proxyの設定（初期化）
4. ドメインの取得
5. SSL証明書の取得
6. Load Balancingの構築
7. DNSの設定
8. IAPの設定
9. Cloud Runの構築（フロントエンド側）
各フローの実装周りの話
ログイン認証 + IDトークンの保持
バックエンドへのリクエスト
まとめ
はじめに
現在、趣味でWebサービスを作っていますが、そのWebサービスに対して、ログイン認証機能を構築することで、特定のユーザーだけがアクセスできるようにしたいと思いました。
※現在使っているサービスの機能は過去の下記記事に記載しております。
ログイン認証をどうやって実現したか
ログイン認証はいくつもの実現方法があると思いますが、今回はサービスをGCP環境に構築しているのもあるため、GCP上のサービスを使って、ログイン認証を実現することを考えました。
そこで、Identity PlatformとIdentity Aware Proxyを利用して、ログイン認証を実現することを考えました。
構成イメージとしては、下記が限りなく近いです。要因としては、下記が挙げられます。
- 現状はフロントはWebアプリのみだが、将来的にモバイルアプリを作る可能性があるため、バックエンドAPIに対してLBを配置したい
- モバイルアプリやフロント側アプリは誰でもアクセス可能だが、バックエンドAPIは認証トークンをつけて、アクセス制限をしたい
Identity Platformとは？
端的に言うと、GCPで提供している認証サービスです。Firebase Authenticationの上位互換なイメージです。詳細は下記の記事にまとまっておりますので、ご覧いただけると幸いです。
OIDC、SAMLなどの認証方式をサポートしていますが、今回はシンプルにEメールアドレス・パスワード認証としています。
※この場合、GCPコンソールで、Identity Platformの画面からユーザーを追加することも可能です。
Identity Aware Proxyとは？
端的に言うと、APIサーバーなどのリソースを保護するためのサービスになります。シンプルに認証されたユーザーのみをアクセス可能にするだけではなく、ユーザーごとにアクセス制御を行うことも可能です。詳細は下記の記事やドキュメントをご覧ください。
今回は、バックエンドのAPIサーバーとしてCloud Runを利用しているため、IAPを用いて、Runへのアクセス制御を行います。
認証関連について構築した構成図
下記のような構成図となります。処理フローとしては、下記です。
- ログイン認証：フロント側でEメール・パスワードを求め、その情報を用いて、Identity Platformで認証処理を実施（フロント側では、Firebase Auth SDKを用いると楽に実装が可能となる）
- IDトークンの保持：認証OKの場合、ユーザーごとのIDトークン（JWT）情報が払い出されるため、それをフロント側では保持する
- バックエンドへのリクエスト：フロント側からバックエンドのAPI（LB + Identity Aware Proxy + Cloud Run）に対してリクエストを送る際に、Authorization: BearerヘッダーにIDトークンを付与して、送信する（詳細はこちらを参照）
上記それぞれのステップにおいての実装周りの話は後述します。その前に、上記インフラを構築する際の手順について触れていきます。
インフラの構成手順
前述した認証に関する構成を組むために、下記に箇条書きとなりますが、手順を記載します。
※多くの手順はterraformで組もうと思って実装中ですが、一部はterraformで自動的な構築ができない部分もあります。OAuth認証画面の構築などが該当します。
大まかに下記のステップとなります。それぞれのステップについて、詳細を見ていきます。
- Cloud Runの構築（バックエンド側）
- Identity Platformの設定（初期化）
- Identity Aware Proxyの設定（初期化）
- ドメインの取得
- SSL証明書の取得
- Load Balancingの構築
- DNSの設定
- IAPの設定
- Cloud Runの構築（フロントエンド側）
1. Cloud Runの構築（バックエンド側）
以下の手順が必要となります。ただし、下記は、今回のログイン認証周りとはあまり関連しないため、私の作ったサービスでは必要という理解で大丈夫です。
- artifact registry apiを有効化し、新規でレポジトリを作成
- firestore apiを有効化し、新規のデータベースを構築
- GCSのバケットを構築
- vertex ai apiを有効化
- バックエンドAPIのセットアップを行い、デプロイする（こちらを参照）
2. Identity Platformの設定（初期化）
以下の手順が必要となります。まずは、Identity Platformを利用可能な状態にします。
下記は全て、google cloud console上で実施が可能です。
- identity platformを有効化
- （メール/パスワードの）プロバイダを追加する
- （後追いの実施でもOK）任意のユーザーを追加する
3. Identity Aware Proxyの設定（初期化）
以下の手順で、Identity Aware Proxyが利用可能となります。
下記も全て、google cloud console上で実施が可能です。
- Identity Aware Proxyを有効にする
- ★OAuth認証画面を構成
※★マークがついた部分は、terraformでの自動構築ができない部分となります。
4. ドメインの取得
HTTPS通信とするため、SSL証明書が必要となりますが、その際にドメインも必要となります。そこで、ドメインの取得も行います。
今回は、GCPのCloud Domainsを使って、ドメインを取得します。下記の手順となります。同様にgoogle cloud console上で実施が可能となります。
- cloud domains apiを有効にする
- cloud dns apiを有効にする
- cloud domains経由で、ドメインを作成する
- 生成したドメインに対して、activation処理を行う（メールで対応する。設定したEメールアドレス宛に、verifyのメールが飛んでくるので、メールに記載されたリンク先をクリックすれば良い）
5. SSL証明書の取得
SSL証明書を構築します。
具体的な手順は、こちらのドキュメントから確認が出来ます。
ドメインは前述で作成したものを利用すれば良いです。このタイミングでは、SSL証明書のステータスは、provisioningのままとなります。
6. Load Balancingの構築
Load Balancingを作成します。先ほどのSSL証明書の構築手順と関連して、こちらのドキュメントが参考になります。手順の概要は下記となります。
- Load Balancingの設定
- アプリケーションロードバランサーを設定
- インターネット接続（外部）を設定
- グローバルワークロード
- グローバル外部アプリケーションロードバランサーを設定
- フロントエンドの構成
- 静的IPの新規作成と設定
- 先に構築したSSL証明書を設定
- バックエンドの構成
- バックエンドサービスの新規作成
- サーバーレスネットワークエンドポイントグループを選択し、新規作成
- CDNは無効
- ロギングは有効化
- セキュリティポリシーの設定
- サーバーレスネットワークエンドポイントグループの作成
- リージョンを指定（東京に設定）
- バックエンド側のCloudRunを指定
- ルーティングルールの設定
- パスごとにバックエンドのルーティング先を変更可能（今回は全パスで同一のバックエンドにルーティングするように設定）
7. DNSの設定
取得したドメインとLBの紐付けを行います。
今回はDNSプロバイダとして、Cloud DNSを利用します。Cloud DNSの画面から、LBのIPをwwwなどのAレコードに対して、設定します。詳細な手順はこちらをご覧ください。
8. IAPの設定
Identity Aware Proxyの設定を行い、バックエンド側のRunへのアクセス時にガードをかけるようにします。下記手順となりますが、全てgoogle cloud console上（IAPの設定画面）で実施が可能です。
- IAPの有効化
- 対象となるバックエンドサービス（LB設定時に構築）のIAPを有効化する
- CLIEND_ID, CLIENT_SECRETの確認
- 対象となるバックエンドサービスに対して、「OAuth構成に移動」から、確認が可能
- ただし、IAPが有効の状態だと、上記メニューが確認不可（のように見える）
- Identity Platformのアカウントを使うように設定
- 対象となるバックエンドサービスを指定し、「承認には外部 ID を使用します」をクリック
- 準備したIDPのEmail/Passwordを選択
- ログインページを作成、を選択（自動でrun上にログインページが作成される。今回は利用しない）
- 設定より、HTTPオプションを有効にする
- フロント側がstreamlitなどのpython clientの場合は不要だが、javascript経由のアクセスの場合は、CORS対策として必要となる
9. Cloud Runの構築（フロントエンド側）
最後にフロントエンド側のRunの設定を行い、デプロイします。
基本的な手順はこちらを参照してください。
注意点としては、secret/config.jsonのapiKeyやauthDomainは、Identity Platformの「アプリケーションの構成」画面から確認が可能です。
各フローの実装周りの話
最後に各フロー(前述した3ステップ）の実装周りの話について触れていきます。
ログイン認証 + IDトークンの保持
こちらの実装が参考になります。
class LoginHelper:
def __init__(self) -> None:
# Identity Platformの認証処理を行うためのインスタンスを取得
with open(os.path.join(os.path.dirname(__file__), "secret", "config.json")) as f:
firebase_config = json.load(f)
app = pyrebase.pyrebase.initialize_app(config=firebase_config)
self.__auth = app.auth()
def login(self, email: , password: ) -> User:
try:
user = self.__auth.sign_in_with_email_and_password(email, password)
return User(email=email, id_token=user["idToken"])
except Exception as e:
raise IdentityPlatformException(f"Sign in Error is occured! Exception detail is ")secret/config.jsonに格納した情報から、接続先のプロバイダー情報を判別して、接続をしてくれます。Firebase APIのラッパーライブラリであるpyrebaseを利用しています。
sign in処理で帰ってきたレスポンスからIDトークンを取得しています。（このIDトークンをバックエンドのリクエスト時に利用します）
バックエンドへのリクエスト
こちらの実装が参考になります。
def request_api(self, token: , request_name: , data: ) -> Response:
url = f"/"
resp = requests.request(
"POST",
url,
data=json.dumps(data),
headers={"Content-Type": "application/json", "Authorization": "Bearer {}".format(token)},
)
if resp.status_code != 200:
raise Exception(
"Bad response from application: {!r} / {!r} / {!r}".format(resp.status_code, resp.headers, resp.text)
)
else:
return respシンプルにrestfulなAPIに対するリクエストではあるんですが、Authorization: Bearerヘッダに対して、先ほど認証処理時に取得したIDトークンを付与していることに注意です。
※このトークンがないと、バックエンドのRunの前段にあるIdentity Aware Proxyに弾かれて、リクエストがRunまで届きません。
まとめ
GCPのIdentity PlatformとIdentity Aware Proxyを利用して、特定のユーザーのみがサービスを使えるような環境を構築してみました。
GCP上で公開するサービスを作る際の参考になれば幸いです。ただし、考慮が不足している点（例えば、IDトークンの有効期限が切れたら、リフレッシュさせるなど）もあったりするので、サービス構築に必要な要件を整理して、適切にセキュアなサービスを構築するのが望ましいと思います。
©︎ 2025 - Yard