AWS Cognito - AdminInitiateAuth vs InitiateAuth

Question

We're looking to leverage AWS Cognito for authentication with an architecture that looks like: client (browser) -> our server -> AWS Cognito

With various configurations set, initiateAuth seems no different to AdminInitiateAuth and so I'd like to understand when under these configurations if it matters whether one is chosen over the other.

It seems that when I create an app with a client secret and use initiateAuth, it seems to be almost the same integration experience as adminInitiateAuth that uses the ADMIN_NO_SRP_AUTH auth flow. The latter does not even require AWS credentials as stated in the AWS documentation. My integration with Cognito is as below:

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();

You can see the difference is the different AuthFlow values, calling different methods and ADMIN_NO_SRP_AUTH requiring the UserPoolId parameter which seems superficial to me.

We are also generating the signature based on the client secret which is something that we would handle securely.

Solution 1

I understand that you would like to know the difference between the InitiateAuth and the AdminInitiateAuth API calls in Amazon Cognito. To clarify the usage of the API calls:

• InitiateAuth is a client/browser side API call, and the API call does not need any sensitive credentials to give a challenge and other parameters.
• AdminInitiateAuth is a meant to be run in the server side, and the API call always needs developer credentials to give a successful response. This is because the API call is an AWS SigV4 signed API call.

Furthermore, both the API calls support different Auth Flows as specified below.

InitiateAuth supports the following Auth Flows:

• USER_SRP_AUTH
• REFRESH_TOKEN_AUTH
• USER_PASSWORD_AUTH
• CUSTOM_AUTH

Kindly note that the AWS CLI documentation [a] currently states that ADMIN_NO_SRP_AUTH is a possible value. However, I have tested the API call on my end and I can confirm that the documentation for the CLI is currently incorrect.

UPDATE (12/09/2019): It looks like after this answer was written, Amazon Web Services has updated their documentation to the correct possible values. The documentation now states the following:

ADMIN_NO_SRP_AUTH is not a valid value.

AdminInitiateAuth supports the following Auth flows:

• USER_SRP_AUTH
• REFRESH_TOKEN_AUTH
• CUSTOM_AUTH
• ADMIN_NO_SRP_AUTH
• USER_PASSWORD_AUTH

Example use-case of InitiateAuth: If you want your users to authenticate into your web application.

Example use-case of AdminInitiateAuth: Any use-case that needs server side authentication or access based on specific AWS Credentials to filter that only specific IAM users can authenticate using Cognito.

As stated by george earlier, InitiateAuth would be ideal for your use-case as your application is a client side application. Additionally, if you are concerned about security, you could use the USER_SRP_AUTH with InitiateAuth. For more information about using the USER_SRP_AUTH flow in your production code, you could refer to the following NPM documentation[b].

References

[a]. https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/initiate-auth.html

[b]. https://www.npmjs.com/package/cognito-srp

Solution 2

initiateAuth and adminInitiateAuth do a similar thing, however, they have different use cases and flow.

initiateAuth is used when you have an end user client app. The user enters their creds and they are sent via Secure Remote Password Protocol. If the flow succeeds the end user gets a token back and is allowed access. This flow is used by the Android, IOS and Javascript SDKs because it's to do with the client side.

adminInitiateAuth is used when you don't have a client end user app but a secure back-end app using Java, Python or some other backend language. This method does not accept username-and-password user credentials for admin sign-in but requires AWS credentials.

In your case, if you had a client app ---> Cognito and use for example Android SDK or Javascript SDK directly then you should use initiateAuth from within the SDK passing the user credentials. However, browser -->back-end--> Cognito meaning you have a dedicated back-end so in your case you should adminInitiateAuth. More info here

Solution 3

I too spent quite some time researching scarce documentation on the topic of when to use AdminInitiateAuth vs InitiateAuth.

https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html is supposed to help, but I find it poorly structured and very confusing.

From my understanding, you're right, you can use both approaches on the server:

1. InitiateAuth with AuthFlow=USER_PASSWORD_AUTH (requires app client to be created with client secret).
2. AdminInitiateAuth with AuthFlow=ADMIN_USER_PASSWORD_AUTH (replaced legacy ADMIN_NO_SRP_AUTH)

I believe second option makes more sense for the server usage scenario though. This way you can disable ALLOW_USER_PASSWORD_AUTH auth flow in the app client settings altogether. While probably not a huge risk, it feels cleaner to not have InitiateAuth API open to the public since it's not required.

Comments

[n00b]

Thanks for the response @george. I think what you've answered is the typical use case but hasn't answered my specific question. Using initiateAuth with a user pool that has a client secret seems no different to adminInitiateAuth with ADMIN_NO_SRP_AUTH. The latter does not require AWS credentials and both require a secret hash to be calculated using the client secret.

[n00b]

I've re-worded my question. Perhaps it started off too general when I was looking for a difference in the specific configurations

[n00b]

Thanks for the response @lightyagami. I've edited my original question to ask the crux of what I'm actually looking for rather than starting it off as a general question.