Cognito×Oktaで社内管理画面向けのIdPを構築！一石二鳥の認証基盤の作り方

STORES 技術推進本部の id:atpons です。

今回は、STORESにおける内部向けの管理画面の認証を統合し、社内外のユーザーを統一的に扱える認証基盤を構築した話を紹介します。従来のOktaとアプリケーションの連携から、Amazon Cognito User PoolとOktaを組み合わせたハイブリッドな認証システムへと移行し、開発者体験とセキュリティの両方を向上させました。

これまでの課題

STORESでは、複数のプロダクトをつなぐ統合画面を開発しており、その中に管理画面が存在します。これまでも複数のプロダクトごとに管理画面を運用しており、それぞれでOktaアプリケーションを作成して認証を行っていました。

しかし、運用していく中でいくつかの課題が浮き彫りになりました。

新しい管理画面を作るたびに、Oktaアプリケーションの作成が必要だった
社外のユーザーが権限を持ちたい時、STORESではOktaに追加する必要は元々なく、この運用のために社外のユーザーがOktaを利用するなど、運用が複雑になっていた
ユーザーのグループ管理や権限制御が管理画面ごとにバラバラで、統一されていなかった

特に、社外委託先のユーザーに対しては、Okta以外の認証手段を提供する必要があり、認証方式が分断される問題もありました。

解決策の検討

これらの課題を解決するため、このような方針で新しい認証基盤を設計しました。なお、ベースとなるIDaaSは、社内では元々AWSを利用していたこともあり、Amazon Cognitoをベースとして構築することにしました。

各管理画面は単一のIdP（Cognito User Pool）と連携すればよい状態を作る
AWS側でアプリケーションクライアントを管理できるようにし、Oktaアプリケーションの申請を不要にする
社内ユーザーはOktaをフェデレーション、外部ユーザーはCognitoの認証を利用する
Cognitoのグループをアプリケーションに渡すことで、管理画面単位のロールによる権限制御を実現する

アーキテクチャの全体像

構築したシステムの全体像は以下のような構成になっています。

graph LR
    subgraph Amazon Cognito IdP
        A[Cognito User Pool]
        C[Okta]
        D[ID/PW Auth]

        A -- STORES社員 --> C
        A -- 社外ユーザー --> D
    end

    B[社内管理画面]

    B -- OpenID Connect --> A

Amazon Cognitoが中心となり、社内ユーザーはOktaとフェデレーション、外部ユーザーは直接Cognitoでユーザー・パスワード認証を行います。

各管理画面は、CognitoからOpenID Connectでユーザー情報とグループ情報を取得し、それに基づいて認可を行います。

ユーザー管理画面の実装

認証基盤だけでなく、管理者がCognitoのユーザーやグループを管理できるWeb UIも構築しました。この管理画面自体もCognito認証を利用し、Lambda@EdgeとCloudFrontを活用したサーバーレス構成で実現しています。

graph LR
    E[CloudFront]
    F[認証 Lambda@Edge]
    G[管理画面 API Gateway]
    H[管理画面 Lambda]

    E --> F
    F -->|IDトークン付与| G
    G --> H

この管理画面では、指定された管理者が以下の操作を行えるようにしています。

外部ユーザーの追加・削除
グループへのユーザーのアサイン
グループの作成・管理

認証フローの詳細

実際のユーザー認証は、Cognitoのログイン画面でどちらかを選択してもらい、ログインします。

社内ユーザー
- CognitoがOktaにフェデレーションし、普段使っているOktaの認証情報でログイン
外部ユーザー
- Cognitoのユーザー・パスワード認証を利用してログイン

どちらの場合も、最終的にはCognitoから同じ形式のIDトークンが発行され、アプリケーション側では認証方式の違いを意識する必要がありません。

少し困ったこと

実装に当たっては、いくつか困ったことが発生しました。

TOTPを利用する場合はメールなどの手段が必要

Amazon CognitoではTOTPをサポートしていたので、最初の実装時はメールを利用せずに、仮パスワードを入力してもらった後、TOTPのみ設定してもらい、何かリセットが必要になったら社内からリセットをする方法で実装することを検討していました。

しかし、Amazon CognitoではTOTPを管理者からリセットすることはできず、ユーザーから行う必要があるため、この方法をとることが出来ませんでした。一旦現状は、メールを併用した認証になっています。

メールを送信する場合はAmazon SESが必要

実際にメールを併用することにしたのですが、Amazon Cognitoでは配信されるメールはAmazon SESを経由させる必要があります。なので、外部ユーザーのメール認証やOTPを利用する場合はAmazon SESを設定する必要がありました。

今回は新しくAmazon SESの設定を行いメールを送信することができました。

運用の改善効果

この認証基盤の導入により、以下のメリットが生まれました。

開発速度の向上

新しい管理画面の追加時に、Oktaアプリケーションの申請が不要になりました
AWS側でクライアント設定を完結でき、認証情報の払い出しが簡単になりました

運用の簡素化

Cognito内で自由にグループを作成できるため、Oktaとは切り離した形でグループを管理することができ簡単になりました
社内外のユーザーを統一的に扱えるようになりました

まとめ

今回は、Amazon Cognitoを中心とした認証基盤によって、管理画面の認証課題を解決した取り組みを紹介しました。Oktaとのフェデレーションを維持しつつ、外部ユーザーにも対応できる形を整え、開発者体験とセキュリティを両立できました。

この事例が、管理画面における開発者体験を向上させる取り組みの参考になれば幸いです。

STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。