2
私はWebアプリケーションを作っています。 （S3の角2とAPIゲートウェイを介したラムダのAPI）。認証のために、私はコグニートとカスタムオーソライザの両方でプレイしました（私は、カスタムオーソライザとコグニートを介してGoogleとFacebookで動作するように認証を設定しました）。カスタムオーソライザの場合、私はauthroizationヘッダーを介してトークンを渡しています。私のカスタムオーソライザはそれを検証します。カスタムオーソライザとamazon apiゲートウェイ用のCognito認証 - Webアプリケーション
私は、先に進むべきか、賛否両論があるのかをアドバイスしています。私は考えることができたものは以下のとおりです。
AWSのcognito：
賛否
- AWS SDKはあなたのためにすべてを処理し、あなたの認証プロセスで多くのミスを犯すことはできません。
- IAMを介したAWSリソースの詳細なアクセス制御。
- すべてのAPIの前にある追加のラムダ関数は、認証には必要ありません。
短所
- 特にクライアント側でAWS SDKを使用する必要があります。プログラマーはこれをツールチェーンに追加し、開発中に使用する必要があります。余分な複雑さを追加します。
- 必要なアクセスはAPIゲートウェイのみであるため、リソースの詳細なアクセス制御は実際には必要ありません。
カスタムオーソ
賛否
- は、あなたがそれを望むように、あなたの認証メカニズムを持つことができます。認証と認可の究極のコントロール
- UIに標準トークン（JWT）を使用してAPIをコールさせることができ、開発者のフローは同じままです。 AWS SDKの特別な考慮事項はありません。
短所
- 認証は、思考と構築するために多くの労力を必要とします。
- いくつかの重要な側面が欠落する可能性が常にあります。
- それはホイールを再発明するようなものです。 Amazonがあなたのためにそれをしてくれたのはなぜでしょうか。
私は今、カスタムオーソライザに向かっています。トピックについてのアドバイスが必要です。
PS：私が投稿した質問には明確な答えはありませんが、アプリケーションの認証を決定しようとする人にとっては大きな助けになるでしょう。
私はCognitoチームのメンバーです。あなたの賛否両論は妥当と思われます。あなたのアプリケーションのニーズに大きく左右されたいのですが、Cognitoの認証情報のスコープ、リソースを埋め込まずにAWS認証情報を安全に取得するという概念、すべてのユーザーの一意の識別子、認証されたものと認証されていないユーザーの概念が最も一般的な理由ですここではCognitoの連合アイデンティティを使用するかもしれません。 –
あなたのアプリケーションのニーズに基づいて、それを使用するかどうかはあなたの呼び出しです。私が言及した理由のほとんどは、それが適用されるよりも適用されない理由のように聞こえるので、それがなくても問題はありません。 –
ありがとうございました。私は自分のアプリケーション用のカスタムオーソライザを使いました。しかし、私は後で、S3へのファイルのアップロードがAPIレイヤーを追加し、10 MBの要求サイズ制限のためにAPIゲートウェイを打つのがうまくいかないと考えました。今はすべてのAPIにカスタムオーソライザを使用し、ファイルをアップロードするにはCognitoを使用しています。 – Prabhat