8月28日、Josh Karamuthが「I Used AWS Cognito for a Startup. I Wouldn't Do It Again.」と題した記事を公開した。Auth0・Firebase Auth・カスタムJWTと複数の認証基盤を扱ってきたエンジニアが、スタートアップでAWS Cognitoを採用した実体験をもとに、その設計上の落とし穴と開発者体験の問題点を詳細に綴っている。
AWS Cognitoは、AWSエコシステムに組み込まれた認証・認可サービスで、月間アクティブユーザー5万人まで無料という価格設定から、AWS上でサービスを構築するスタートアップに広く採用されてきた。スタートアップが認証基盤を選ぶ際、「無料」「既にエコシステムの中にある」という理由は強力な動機になる。しかしKaramuthのチームは、その選択の結果として想定外のエンジニアリングコストを払い続けることになった。
最大の罠：ユーザープールの属性は後から変更できない
記事の中で最も多くのエンジニアに刺さるであろう話が、ユーザープールの属性設定が作成後に変更不可能という制約だ。
Karamuthが実装したのはシンプルなユースケースだった。メールアドレスだけで認証する、ユーザー名なし。サインアップ時にメールを入力して確認し、パスワードを設定する――それだけだ。
ところがCognitoは、「email」という属性をコア属性・エイリアス・カスタム属性の3通りで扱い、それぞれの設定がコンソールの複数画面に分散していて、相互依存関係はどこにも明示されていない。初期設定で「カスタム属性として設定すべきでなかったものをカスタム属性にした」という小さなミスが、後に取り返しのつかない問題になった。
I made a mistake in the initial setup. A small one. I had configured something as a custom attribute that should have been a standard one. No problem, I thought. I'll just change it.
You cannot change it.
カスタム属性として作成したものは、永遠にカスタム属性のままだ。認証スキームがその属性間の関係に依存していて、設定を誤った場合の選択肢は実質2つしかない。
- ユーザープールを丸ごと削除して最初からやり直す
- ユーザーを新しいプールへ移行するスクリプトを書く
本番稼働中のアプリでは「削除して作り直し」は選べない。パスワードリセットの再案内、ユーザーへの謝罪、移行スクリプトの実装――すべてが、コンソールのドロップダウン一つの曖昧さから始まった。
Amplify v6という名の人質
もう一つの痛い話が、AWS Amplifyのメジャーバージョンアップへの対応だ。
Amplify v5でCognito連携の認証フローを実装し、テストし、本番投入した。数週間後、バグ修正のためにコードに戻ると、コンソールに非推奨の警告が出ていた。「最新版にアップデートすれば済む話」と思ったのが間違いだった。
Amplify v6はAPIを一部変更したのではなく、アーキテクチャを根本から作り直した。 UIフロー全体が依存していた関数が消えていた。移行ガイドは存在するが、「ランドマークが半分欠けた宝の地図」とKaramuthは表現する。
彼がやったのはリファクタリングではなく、書き直しだ。本番で正常に動いていた認証ロジックを、ライブラリの方針変更のために一から再実装した。
開発体験を蝕む3つの慢性的な問題
上記2つが「急性の痛み」だとすれば、日常的にエンジニアを消耗させる慢性的な問題も指摘されている。
ドキュメントの混乱。 エンタープライズアーキテクト向けのアイデンティティプロトコル解説と、フロントエンド開発者向けのログインフォームの実装例と、モバイルSDKの解説が混在している。コードサンプルも旧JavaScript SDK向け、Amplify v1向け、生のAWS SDK向けが混在しており、どのバージョンの話か明示されていないことが多い。「Cognito カスタム属性バリデーション」で検索すると、事前に4ページ読んでいることを前提としたページに飛ぶ。
ローカル開発環境が作れない。 Cognitoはクラウドベースのサービスであるためローカルインスタンスを立てられず、常に実際のAWSエンドポイントを叩く必要がある。コミュニティ製のローカルエミュレーターは存在するが、実際のサービスとの挙動の差異によってバグが本番まで漏れ出すケースがあった。
ホストUIのカスタマイズはほぼ不可能。 ロゴ変更と一部CSSの調整はできるが、レイアウトや構造は変更不可。本格的なブランディングが必要なら「SDKで自前UIを作れ」というのがコミュニティの共通見解だ。
「無料」の認証基盤に払ったコスト
Karamuthが出した結論は明確だ。認証基盤はエコシステムの都合ではなく、開発者体験で選べ。Cognitoのドキュメント解読と破壊的アップデートへの対応に費やしたエンジニアリング時間は、Auth0やClerkといった専業の認証プロバイダーを使い続けた場合のコストをはるかに上回ると彼は述べている。
なお彼は現在もそのプロジェクトでCognitoを使い続けている。「抜け出すには深入りしすぎた」からだ。コンソールを開くたびに、「皿を洗わず、しかも自分の物を勝手に借りる昔のルームメイト」のような静かな憤りを感じると締めくくっている。
詳細はI Used AWS Cognito for a Startup. I Wouldn't Do It Again.を参照していただきたい。
