AWS Cognito-AdminInitiateAuthとInitiateAuth

Question

次のようなアーキテクチャで、認証にAWS Cognitoを活用することを検討しています：client (browser) -> our server -> AWS Cognito

さまざまな構成が設定されている場合、initiateAuthはAdminInitiateAuthと同じように見えるため、これらの構成の下で、どちらを選択するかが重要かどうかを理解したいと思います。

_client secret_でアプリを作成し、initiateAuthを使用すると、_ADMIN_NO_SRP_AUTH_認証フローを使用するadminInitiateAuthとほぼ同じ統合エクスペリエンスのようです。後者は、AWSのドキュメントに記載されているように、AWS認証情報を必要としません。 Cognitoとの統合は以下のとおりです。

initiateAuth：

_  const payload = {
    AuthFlow: "USER_PASSWORD_AUTH",
    ClientId: cognitoClientId,
    AuthParameters: {
      USERNAME: username,
      PASSWORD: password,
      SECRET_HASH: generateSignature(username)
    }
  }
  const response = await cognitoClient.initiateAuth(payload).promise();
_

adminInitiateAuth：

_  const payload = { 
    UserPoolId: userPoolId,
    AuthFlow: "ADMIN_NO_SRP_AUTH",
    ClientId: cognitoClientId,
    AuthParameters: {
      USERNAME: username,
      PASSWORD: password,
      SECRET_HASH: generateSignature(username)
    }
  }
  const response = await cognitoClient.adminInitiateAuth(payload).promise();
_

違いは、異なるAuthFlowの値、異なるメソッドの呼び出し、および_ADMIN_NO_SRP_AUTH_がUserPoolIdパラメータを必要とすることであることがわかります。

安全に処理できるクライアントシークレットに基づいて署名も生成します。

Answer 1

私も、AdminInitiateAuthとInitiateAuthをいつ使用するかというトピックに関する希少なドキュメントの調査にかなりの時間を費やしました。

https://docs.aws.Amazon.com/cognito/latest/developerguide/Amazon-cognito-user-pools-authentication-flow.html は役立つはずですが、構造が不十分であり、非常に紛らわしいです。

私の理解から、あなたは正しい、あなたはサーバーで両方のアプローチを使うことができます：

1. InitiateAuth with AuthFlow=USER_PASSWORD_AUTH（アプリのクライアントをクライアントシークレットで作成する必要があります）。
2. AdminInitiateAuthをAuthFlow=ADMIN_USER_PASSWORD_AUTHに置換（従来のADMIN_NO_SRP_AUTHに置き換え）

サーバーの使用シナリオでは、2番目のオプションの方が意味があると思います。このようにして、アプリクライアント設定でALLOW_USER_PASSWORD_AUTH認証フローを完全に無効にすることができます。大きなリスクではないかもしれませんが、InitiateAuth AP​​Iは必要ないため、公開しないほうがクリーンです。