‫So, just a short theory lecture
‫to reiterate on what I've said in the hands-on.
‫So first, we can use Lambda Triggers
‫so that the Cognito User Pools
‫can invoke any Lambda function synchronously
‫on some of these triggers,
‫and we've seen most of them,
‫but so, the important ones are going to be
‫around the authentication events,
‫so pre-authentication, post-authentication
‫and pre-token generation,
‫we can have a Lambda trigger, for example,
‫to accept or deny your sign-in request, to log events
‫after a successful authentication for custom analytics
‫or to augment and suppress token claims.
‫Then for the sign-up, we can do a pre sign-up,
‫post confirmation and migrate user Lambda trigger.
‫This will be helpful, for example, in this one,
‫to give a custom welcome message or event logging
‫for custom analytics after a user has signed up.
‫Finally, we can customize the messages
‫that we send to the user thanks to a Lambda function,
‫and finally, we can modify the token creation
‫by adding or removing attributes in ID tokens.
‫Another very nice thing about the Cognito User Pools
‫is that we had a hosted authentication UI
‫and that was allowing us not to program
‫that UI in our application,
‫we can just reuse the one Cognito has created for us,
‫and with it we can handle the sign-up and signin workflows.
‫In using this hosted UI, we have a foundation
‫with all the integration for social logins, OIDC or SAML,
‫so we don't have to reprogram everything,
‫and if we wanted to include this UI
‫into our own application,
‫then we can customize the logo, as we've seen,
‫and we can customize the CSS
‫to make it look like it belongs to our websites.
‫So this will be a login screen
‫with your own custom logo in big.
‫Now for the hosted UI, you may want to host it
‫on your own domain and therefore a custom domain.
‫So the trick you need to know
‫is that if you're using custom domains
‫with Cognito User Pools, regardless of where it is created,
‫you must create an certificate for using HTTPS.
‫That certificate must be in ACM, okay?
‫And the region it needs to be in must be us-east-1.
‫You have no other option.
‫So, this is a trick because,
‫well, even if you have a Cognito User Pool in,
‫say eu-west-1, you must create it
‫in us-east-1, your certificates.
‫Now the custom domain, you must define it
‫in the app integration section of Cognito User Pools
‫because this is going to be a configuration
‫for all app claims.
‫This is a general configuration.
‫Another very nice feature of Cognito User Pools
‫is adaptive authentication.
‫So the idea is that you allow your users
‫to sign-in as normal using their username and password,
‫but then with adaptive authentication,
‫in case there is a suspicious login,
‫then the sign-in can be blocked
‫or we can reqUIre multi-factor authentication.
‫How does it work?
‫Well, each sign-in attempt
‫is going to be examined by Cognito,
‫and then is going to be a risk score,
‫low, medium or high for how likely the sign-in request
‫is going to be from a malicious attacker
‫or an unknown login,
‫and so, if that's the case, then users may be prompted
‫for a second multifactor authentication
‫only when there is risks.
‫So you as a normal user, that Cognito is used to,
‫maybe you log in from your own computer in your workplace,
‫so you're good, you can sign-in using a password,
‫but then if somehow you or someone else's
‫tries to log in from a new location
‫using your password again, Cognito may say, "Hm,
‫that looks like a suspicious login.
‫Please use MFA to verify your identity."
‫So the risk score is based on many different factors,
‫such as if the user is using the same device as usual,
‫the location, the IP address, and so on.
‫And in case of compromised credentials,
‫there is account takeover protection
‫and there will be phone and email verification as well.
‫On top of it, any kind of work done
‫by the adaptive authentication mechanism
‫is going to be seen in CloudWatch logs,
‫such as the sign-in attempts,
‫the risk score, the fail challenges, and so on.
‫Now, when you log in with a Cognito User Pool,
‫what you get back from the pool
‫is a JWT Token or a JSON Web Token.
‫And so these are Base64 encoded.
‫You'll have what's called the header,
‫the payload and the signature,
‫and so Base64 is allowing you to transmit
‫that over the network easily,
‫and then it's going to be decoded and it looks like this.
‫So this is a JWT Token payload.
‫The header is not represented,
‫that's the first line
‫and the token signature is not represented,
‫that's the last line.
‫What I've shown you is the payload,
‫and the payload indicates a lot
‫of information about the user.
‫We'll go over it in a second, but first,
‫when you receive a JWT, to trust what's in the payload,
‫you need to verify the signature.
‫So, the signature is the thing at the very bottom,
‫and there is an algorithm that allows you to say,
‫"Okay, if the signature is correct
‫then I can trust whatever information is in the payload,
‫because otherwise, if that wasn't the case,
‫you could declare here whatever user,
‫and so there are libraries to verify a JWT Token,
‫and once it's done, you can use the payload,
‫and so the payload contains user information.
‫So here for example, we have the sub UUID,
‫which represents the user ID
‫in the Cognito User Pool database.
‫So using that sub UUID, you could, for example,
‫recover any kind of information you want
‫about your user that you've stored in the Cognito database.
‫So, from the Cognito database, you could recover,
‫for example, the user email, the given name,
‫the phone number, any attributes you've defined
‫as part of your Cognito User Pool.
‫Then there's some other fields we can look at.
‫For example, you'll have the username, the Cognito groups.
‫You may have also the expiry of this Jason Web Token,
‫all of this, as part of the payload,
‫but again, if you need extra information,
‫please look up the user in the Cognito user portal database
‫using the user ID with the sub UUID.
‫Okay, so that's it.
‫We've seen all we need to know about Cognito User Pools.
‫I hope you liked it, and I will see you in the next lecture.