AWS Cognito でスタートアップの認証を実装したが、二度と使いたくない
I Used AWS Cognito for a Startup. I Wouldn't Do It Again
スタートアップの認証にAWS Cognitoを採用した開発者が、ドキュメントの混乱、Amplify v6での破壊的変更、ローカル開発の難しさ、カスタマイズの制限、属性設定の取り返しのつかなさなど、数々の困難を経験したことを率直に綴る。無料枠やエコシステム統合の魅力に惑わされず、開発者体験を最優先に選ぶべきだと主張する。
一度ユーザープール属性をカスタム属性として作成すると、それは永遠にカスタム属性のままです。
HNでの議論
118- wilkystyle
Cognitoのドキュメントを読むのは、3つの別々のマニュアルをミキサーにかけて、そこに古いStack Overflowの回答を風味付けで振りかけたような感じがする。
これは基本的にAWSのドキュメント全般に対する私の経験だ。ほぼ常に、(1)実際に使うにはあまりにも高レベルすぎるか、(2)あまりにも冗長で、私が解析して捨てる必要のある大量の余計な情報があるかのどちらかだ。
ほんの一例を挙げると、最近AWS Partner CentralアカウントをAWS Managementアカウントにリンクする必要があったが、そのプロセスとドキュメントは痛いほど複雑だった: https://docs.aws.amazon.com/partner-central/latest/getting-s...
- solatic
次回は、AWSサービス統合の利便性ではなく、開発者体験を第一にツールを選ぶつもりだ。Cognitoの問題をデバッグするのに費やした時間で、有料の認証プロバイダーを数年分支払えたはずだ。
ユーザーのパスワードハッシュをエクスポートして、必要なら別のベンダーにシームレスに移行できるようにしてくれる有料認証プロバイダーはいくつあるだろうか？
認証の問題全体は、(a)ログイン画面は認証されていないユーザーに表示されるが、その中には攻撃者も含まれ、DDoSから巧妙に細工された悪意のある入力まで、ユーザーの秘密を奪おうとするあらゆることをするため、大規模な本番稼働で実績があり、本番での数々の戦いを経験したものを選ぶべきであり、(b)マネージドベンダーに頼る必要性は、ローカル開発、ベンダー独立性、データポータビリティ、その他の良いエンジニアリングプラクティス(TM)と非常に緊張関係にある。
確かに、AWS Cognitoは最悪だ。多くの点で、製品は行き詰まっているように感じる。物事をリリースし、機能させ、安定させるために妥協するのは最悪だ。しかし正直なところ、(b)を(a)より優先するつもりがない限り(そうすべき時もある、特にファイアウォールの背後にあるイントラネットアプリケーションで、そういった攻撃の影響を受けにくい場合)、Keycloakのようなものを選ぶか、Cognitoよりはるかに悪い選択肢もある(震え上がる、Okta、震え上がる)。
- patwolf
Cognitoでの私の経験は、著者の経験とまったく同じだ。以前は主にAuth0を使っていたが、新しいプロジェクトでは安くなるのでCognitoに切り替えた。
メールアドレスが大文字小文字を区別するのが気に入らないが、それを変更したいと思っても、残念ながらユーザープールを最初から作り直す必要があり、移行する方法はない。
- mannyv
Cognitoチームとパスワードリセットについて話し、パスワードを設定できることが必須機能だと主張したのを覚えている。彼らは「いいえ、なぜリセットフローを経由せずに済ませる必要があるのですか？それはセキュリティ上の問題です」と言っていた。もちろん、数週間後には、すべての管理者がそれをする必要があるため、彼らはそれを追加した。つまり、ある時点で、実務経験がほぼゼロの人々がそれに取り組んでいたのだ。
Cognitoの2つの利点は、(1)ローカルに資格情報を持たずにサービスにログインできること、(2)Cognito IDを使用してAWSリソースへのアクセスを提供できることだ。おそらく今はそれができるが、多くのソリューションは依然としてデバイス上のキーを必要としており、これは明らかなセキュリティ上の問題だ。
また、認証に独自のバックエンドを使用することで、認証がCognito内に閉じ込められないため、物事を管理しやすくなった。
- cldcntrl
Cognitoには確かに粗い部分があるが、この記事はそれらにはあまり触れていない。
たとえば、Cognitoを介して動作するSAML統合を実装しようとしたことがあれば、そのフローがどれほどわかりにくいか分かるだろう。私は実際に、Cognitoチームと協力して、本当に致命的なバグを修正してもらわなければならなかった。
間違いなくAWSで最も洗練されたサービスではないが、内部事情を知っていれば使える。
- mikigraf
バックアップや、このようなサービスに期待する他の基本的な機能については言うまでもない。AWSは、買収(Auth0やWristbandのような小規模な会社?)を行ってサービスを再構築するか、単に廃止すべきだ。その代わりに、企業が依存する重要なサービスが宙ぶらりんのままになっている...
- nater5000
AWS Cognitoが最も簡単な認証サービスではないという点には同意するが、一度理解すれば、他のものと同じように機能する。
私は著者が説明したのとまったく同じ苦労(そしてそれ以上)を経験してきた。しかし、一度それらの苦労を経験すれば、それらに対処する方法が分かる。ソフトウェアでは、一度理解すればそれで終わりだ。
Cognitoの使用を大規模に拡張したとは言えないが、すべてをAWSにまとめておくことは、その手間をかける価値がある(少なくとも状況によっては)。Cognitoは実際のカスタマイズのオプションを豊富に提供している(ホスト型UIは初期テストにのみ良く、その後は捨ててしまう)。そしてもちろん、LLMはCognitoを他の認証サービスと同じくらい簡単に扱える。私がCognitoを設定したときはLLMを使う余裕はなかったが、それでも認証には私の頼みの綱であり、Claudeもそれでつまずくことはない。
- dabinat
個人的には、特定のベンダーに縛られ、そのベンダーが質の悪いサービスを提供したり、大幅に値上げしたりした場合に切り替えが難しい技術にビジネスを構築することは決してないだろう。