Getting the AWS Cognito advanced security authentication event for a given login

AWS Cognito advanced security lets you see authentication event details in the Cognito console and via the CLI and API. If you’re set up correctly, you’ll get:

  • Timestamp
  • The user’s ID and username
  • Event type
  • Success or failure
  • Risk level and risk decision (if adaptive security is enabled)
  • Any challenges presented during the event (like whether a password was used, or MFA was prompted)
  • A device summary – consisting of a browser name/version and operating system
  • IP address
  • City
  • Country
  • Whether compromised credentials were used
  • The user pool ID that triggered the event

You can look at auth events on a per-user basis in the console and via the CLI, but your filtering options are very limited. You cannot:

  • Query all events in a user pool by IP address
  • See whether multiple users are signing in from the same IP address
  • Identify a date-ordered list of suspicious or failed logins

If you want to do this, you probably want those events available to your own code so that you can store them in a database or similar.

You can choose to forward logs of these events to S3, Firehose or Cloudwatch Logs if you’re using the Cognito Plus plan – but the logs are generated post-hoc (that is – after the login has taken place), and asynchronously.

This means that you can’t get this kind of information directly from the authentication call your app might be making – like AdminInitiateAuth.

If you want to correlate auth events shipped to your log destination to requests to things like AdminInitiateAuth, helpfully Cognito ships the AWS requestId that was generated when making the request in the auth event payload.

So, if you want to correlate a sign-in with additional data later on (for example, if you already capture IP information and success/failure, but want to have an eventually-consistent store that includes some of the above fields) then you can record the requestId on the response’s ResponseMetadata object. Then you can hook a Lambda to Firehose or S3, parse the events as they arrive and use the request ID to identify which database records to create or update to avoid creating duplicates.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.