cognitoの導入・実装の難しさ
認証にcognitoを利用しているとの事
それ聞いただけで、「やばい！」って感じた
「なぜ、cognitoを採用したんですか？」
「簡単だから」
認証してそれなりに動くところまでなんとかいった後
「どこがやねんッ！」って思いました。
その経緯を記載します。
- ユーザー作成してアクティベートまで
- アプリケーションでの使い方
- 認証の流れ
- 書き換えが可能！？
- API GatewayのAuthorization機能
- AWS Cli以外でのユーザーの承認プロセスは？
- ソースコード以外がビジネスロジックを保持
ユーザー作成してアクティベートまで
AWSの機能なので、ユーザーをコンソールから”簡単”に作成できるのかと思いました。
しかし、いくらcognitoの管理画面から設定してもなかなかうまくいかない😵💫
ユーザーは簡単に作成できても、なかなか確認済みの状態（＝使える状態）にならない！！😵💫
カスタム属性の登録もコンソール上では行えなかったです。
色々調べるとコンソールからではなく AWS CLIを使えとの事
その時点で既に面倒ではあるが仕方なしにまずAWS CLIが使える状況に持っていきました
AWS CLIのインストールも詰まった所があったけど、今はそこまで覚えてない。。
参考URL
AWS CLIを使ってCognitoユーザーステータスのFORCE_CHANGE_PASSWORDをCONFIRMEDにしてみる | DevelopersIO
AWSのCLIが使えるようになったら次にユーザープールIDとクライアントIDを取得します。
ユーザープールIDしかりクライアントIDコンソールのページを開いてどれがどれかを確認します。
ID探しもかなり面倒だった記憶があります。
その上で下記のコマンド
もちろんユーザープールIDしかりクライアントIDを適切な値にしないといけません。
このコマンドがうまくいけば、sessionが返ってきます。
sessionがコマンド後に表示されるのでそれをすかさず次のコマンドにコピペしないといけません。
そのコマンドが下記です
このセッションの"AYAmg"の部分は本当はもっと長い文字列です。
１回目のコマンドのあとに参考になるWEBページを見ながらやってたら有効期限切れになってしまいました。
この時点で、クライアントIDを間違えてとか、ユーザープールIDがそもそもとかでだいぶ疲れているところにこれ😵💫
でも、ユーザーを作成しないといけないので、ゲームみたいに１回目のコマンドで得たパスワードを２回目にコピペしました。
それで、なんとかステータスがFORCE_CHANGE_PASSWORDからCONFIRMEDに変更することができました。
色々気分が汗だくになりながらも、ふと我にかえると、まだユーザーを作成したにすぎない。。
アプリケーションでの使い方
次にそのアプリケーションにどう組み込まれているかを調査
そもそも、どうログインしているのか誰もわかっていない現場って。。。
フロントエンドからバックエンドを介さず直接cognitoのURLにアクセスしにいってます。
そもそもが間違ってます。
フロントエンド、アプリからログイン情報を渡して、アクセストークンをもらってもそれをどう使うの？
ってなります。
そのアクセストークンをバックエンドつまりサーバーサイド側に渡しているかの確認
サーバーサイドにアクセストークンを渡してはいるものの、サーバーからcognitoへのアクセスがない！！
二度見を３回ぐらい確認したけども、アクセスしていない！！😵💫
じゃぁ、どうやってユーザーを識別しているのかをソースコードを見て調査
その時点でドキドキと不安でいっぱいになりながらコードを追っていきます。
どうやらcognitoの"sub"というデータでユーザーを認識しているみたいです。
ユーザーが作成してからAWS Consoleでこのsubの欄に文字列が記載されています。
その文字列をあらかじめDBのユーザーテーブルに登録しておきます。
適切なユーザー名・パスワードを入力するとトークンと一緒にこのsubも取得できます。
そのsubとトークン、その他もろもろのデータをヘッダーのauthorizationとしてリクエストします。
サーバー側ではそれらのデータの中からsubを取得して自分のDBのuserテーブルのあらかじめ登録しているsubを照らし合わせます。
それで導き出されたデータが該当のデータです。
認証の流れ
authorizationの内容をAWSから提供されているライブラリを利用してverify関数を使っているように見えます。
でもcognitoないしどこかにそのアクセストークンが正しいかどうかのエンドポイントのアクセスが見当たらないです。
verify関数でもトークンの正当性をチェックしてなくてあくまでフォーマットがあってるのかどうかだけのチェックのように見えます。
書き換えが可能！？
ちなみにトークンの他にsub,emailなどもauthorizationにあったのでemailを書き換えてみました
email表示部分がうまく変更され認証も通り、変更されたemailが表示されましたw
authorizationも書き換えられるやん！！
authorization書き換えが可能ならばセキュリティ的にどうなのよってなってしまいます。
token自体はどうなるか書き換えてみたかったけど、書き換えが難しかったのでその時やってなかったです。
今試しに書き換えたらうまく401と認証の不正を防いでたので、どういうロジックでcognitoにアクセスせずに認証しているか不思議です。
なので認証の機能はあってセキュリティは担保されているようです。
Amazonが提供しているAPIなので、セキュリティ的に問題であれば、大問題となるのでちゃんと実装すればセキュリティ的には問題なさそうですね。
API GatewayのAuthorization機能
他にも調べたらAPI GatewayのAuthorization機能が認証の機能を果たすそうです。
tokenチェックをして、トークンが違っていたら401でブロックするという仕組みのようです。
しかし、それだけでは誰のアクセスかを特定できないかと思います。
なので、ここでの実装はsubを一意のユーザーIDのように扱ってユーザーを特定しているのではと思います。
となるとそのsubを書き換えるのでは？と思い書き換えても認証が通ったので、ユーザーのなりすましが可能になります😵💫
AWS Cli以外でのユーザーの承認プロセスは？
ユーザー作成も大変だったのですが、そもそもaws cliコマンドでしかユーザー承認されないのかどうかも調査しました。
AWSエンジニアがコマンドからしかユーザー作成できないとなると基幹システムのuser=スタッフの入れ替わりの度にコマンドが必要になります。
運用としてはuserが増える度にAWSエンジニアが手動でコマンド叩くなんてありえないので、もしこれが本当ならそもそも使えるツールではなくなります。
調べてみるとあるにはありましたが、それようの実装をしないといけないですし、stackoverflowの情報です。
javascript - How can you programmatically create a user in a Cognito User Pool? - Stack Overflow
一般のlaravelとかのフレームワークを使えばconfigファイルにどのセッションを使うかを指定して、ログイン、パスワードの部分の実装するだけです。
このstackoverflowで結局cognitoでも実装が必要となると
AWSコンソールに入ってユーザー作成
AWS cliからコマンドでユーザーをアクティベート
の部分余計手間がかかるかと思います。
データの構造も一般的な場合userテーブルにパスワードカラムが必要になってくるだけです。
その代わりにcognitoの画面を行ったり来たりとなるとメリットの分がデメリットを大きく上回るかと思います。
ソースコード以外がビジネスロジックを保持
のwebサーバーのベストプラクティスでの論じてたようにロジックはできる限りバージョン管理できるプログラミングで行うべき
でもAWSの多くの魅了するツールはできる限りロジックをAWSに持っていこうとします。
なぜなら、そっちのほうがお金が儲かるからです。
これからも今の現場のようなAWSの美辞麗句に騙されて何かしらのツールを使って炎上している現場も増えてくるかと思います
しかしながら、Amazonに騙されている人はAWSの変なツールを使う事が悪いとは誰も言いません「使い方が悪い」「スキルが低い」と解釈します
こんな状態ではAmazonのやりたい放題になってしまいます。
これらの説明をふまえてもまだcognitoの方が使いやすくて簡単って思う人はシステム設計の才能がないかと思います。
登録日：
更新日：