1 00:00:14,720 --> 00:00:20,360 Welcome back to Backspace Academy. In this lecture on the AWS Cognito 2 00:00:20,360 --> 00:00:25,860 authentication service, we'll start off by talking about the Cognito user pools 3 00:00:25,860 --> 00:00:31,669 and how we can use those to create millions of users to access our 4 00:00:31,669 --> 00:00:38,010 applications that are running on AWS. We'll talk about the Cognito federated 5 00:00:38,010 --> 00:00:44,340 ID pools and how we can use a third-party authentication service such 6 00:00:44,340 --> 00:00:48,990 as login with Google or log in with Facebook or a SAML authentication 7 00:00:48,990 --> 00:00:56,040 service to again authenticate and access our applications on AWS. We'll talk about 8 00:00:56,040 --> 00:01:03,619 the Cognito Sync key store database and how we can store data specific for a 9 00:01:03,619 --> 00:01:10,439 Cognito user. We'll talk about how Cognito opens up a whole new world of 10 00:01:10,439 --> 00:01:17,670 modern serverless applications that we can run completely without servers on AWS 11 00:01:17,670 --> 00:01:22,140 and finally we'll talk about troubleshooting and what to do when 12 00:01:22,140 --> 00:01:29,490 things go wrong. Cognito it adds user signup sign in and access control for 13 00:01:29,490 --> 00:01:34,229 your web and mobile applications. So you might have an application that has 14 00:01:34,229 --> 00:01:39,630 millions of users and Cognito can manage all that for you and, those users will 15 00:01:39,630 --> 00:01:45,330 have a username and password to access your application. You can also use a 16 00:01:45,330 --> 00:01:50,700 social identity third-party OAuth provider for the authentication and 17 00:01:50,700 --> 00:01:55,920 integrate that with Cognito such as Facebook Google or Amazon or you could 18 00:01:55,920 --> 00:02:01,830 also use a third-party enterprise identity provider and use that via SAML 19 00:02:01,830 --> 00:02:07,950 Cognito it consists of three services. The user pools which can have millions 20 00:02:07,950 --> 00:02:13,650 of users. Federated identity pools to allow that third-party authentication 21 00:02:13,650 --> 00:02:21,810 through OAuth providers or SAML to applications and also a Cognito sync key 22 00:02:21,810 --> 00:02:29,389 store database that allows you to store information on specific users. 23 00:02:30,050 --> 00:02:35,730 Okay, so on the left there we've got the different ways in which Cognito can 24 00:02:35,730 --> 00:02:41,790 authenticate any users that want access to our application. So we've got social 25 00:02:41,790 --> 00:02:45,360 identity OAuth provider such as Google, 26 00:02:45,360 --> 00:02:49,050 login with Facebook, login with Amazon any of those will be fine. 27 00:02:49,050 --> 00:02:55,830 We can set up a Cognito user pool which will have a list of a pool of users and 28 00:02:55,830 --> 00:03:01,049 they can login using a username and password and finally, we can use an 29 00:03:01,049 --> 00:03:07,370 enterprise identity authentication service provided it is SAML compliant. 30 00:03:07,370 --> 00:03:12,930 Once that's done a token will be issued by the Cognito or actually be issued by 31 00:03:12,930 --> 00:03:17,040 the STS service, security token service, and we'll talk about that in the next slide 32 00:03:17,040 --> 00:03:22,819 and that will allow your users to access through your application 33 00:03:22,819 --> 00:03:29,910 AWS resources such as Amazon S3, your API's. You could set up an API Gateway service 34 00:03:29,910 --> 00:03:35,480 and they could access that as well, securely. Also you can set up a data 35 00:03:35,480 --> 00:03:41,040 synchronization service using Cognito sync, which will be a key store database 36 00:03:41,040 --> 00:03:50,340 which will hold data or information on your particular users. The security token 37 00:03:50,340 --> 00:03:57,000 service or STS for short is a back-end service that provides that security the 38 00:03:57,000 --> 00:04:02,310 low-level security around the IAM service. So it's a back-end service and 39 00:04:02,310 --> 00:04:07,109 it's accessible from the software development kit or the command-line 40 00:04:07,109 --> 00:04:10,470 interface but it's not accessible through the console. So if you go to the 41 00:04:10,470 --> 00:04:15,269 management console and you try and find security token service on the list of services 42 00:04:15,269 --> 00:04:19,200 you won't find it, it's just a back-end service that provides the 43 00:04:19,200 --> 00:04:25,200 nuts-and-bolts to achieve the security of IAM. So it does that by issuing 44 00:04:25,200 --> 00:04:32,010 temporary limited privilege credentials for IAM or federated users for example 45 00:04:32,010 --> 00:04:36,750 if you're using login with Facebook or login with Google or a SAML Enterprise 46 00:04:36,750 --> 00:04:41,400 authentication service. They will be limited privileged credentials. 47 00:04:41,400 --> 00:04:49,110 It achieves this by using JSON web tokens or JWT for short and, 48 00:04:49,110 --> 00:04:54,960 it uses those to secure and authorize the access to your API such as an API gateway 49 00:04:54,960 --> 00:05:01,229 service or other AWS services such as Amazon s3 and, those web tokens there 50 00:05:01,229 --> 00:05:06,990 will be temporary and, they will have limitations on how that, 51 00:05:06,990 --> 00:05:12,479 your user can access your account, for example if it's a root user it will have full 52 00:05:12,479 --> 00:05:16,650 access to your account. If it's someone who's validated through an 53 00:05:16,650 --> 00:05:21,350 authentication service such as logging of Google they may have the access 54 00:05:21,350 --> 00:05:26,460 specifically for read-only not write and it will be only to a certain part of 55 00:05:26,460 --> 00:05:31,979 your application or a certain part of that service such as s3. It's a global service 56 00:05:31,979 --> 00:05:38,639 like IAM and the endpoint for it is STS.amazonAWS.com and 57 00:05:38,639 --> 00:05:44,510 it integrates very well with Cloudtrail. So if you want to see an audit trail of 58 00:05:44,510 --> 00:05:50,160 users that have been issued an STS token then you can see that by setting 59 00:05:50,160 --> 00:05:58,229 up a cloudtrail log. Ok, so here we have a mobile application and it's going to 60 00:05:58,229 --> 00:06:03,930 be using the third-party login with Amazon service to authenticate that 61 00:06:03,930 --> 00:06:09,479 mobile user but, that could also be login with Facebook or, it could be login with PayPal 62 00:06:09,479 --> 00:06:15,120 it could also be a Cognito User Pool that we could log in with 63 00:06:15,120 --> 00:06:20,010 a username and password but whatever it is, it's a service that we use to 64 00:06:20,010 --> 00:06:24,330 authenticate this individual. So once we have authenticated using that third 65 00:06:24,330 --> 00:06:32,130 party service, login with Amazon will hand over a token to that mobile client 66 00:06:32,130 --> 00:06:37,740 and that mobile client will then pass that token over to the AWS security 67 00:06:37,740 --> 00:06:44,340 token service and the AWS STS service will then go back to the login with 68 00:06:44,340 --> 00:06:50,969 Amazon service to authenticate that token. If that token is valid for that 69 00:06:50,969 --> 00:07:00,780 particular user then the STS service creates an AWS temporary JWT a JSON web token 70 00:07:00,780 --> 00:07:08,130 and passes that back to the mobile client. Once a mobile client has that, 71 00:07:08,130 --> 00:07:16,470 they have limited and temporary access to AWS resources and those AWS resources will 72 00:07:16,470 --> 00:07:24,150 be defined in an IAM policy. So if that mobile client has read-only access then 73 00:07:24,150 --> 00:07:29,760 that will be defined in the IAM policy. If that mobile client or that end-user 74 00:07:29,760 --> 00:07:34,830 only has access to a specific part of that database then they will only be 75 00:07:34,830 --> 00:07:38,930 granted access to that specific part. So in this situation they're being given 76 00:07:38,930 --> 00:07:43,350 read and write access to the game score. So they've got a high score 77 00:07:43,350 --> 00:07:48,630 the mobile application can write that back to Dynamodb and it's completely 78 00:07:48,630 --> 00:07:54,720 secure and completely straightforward because we're using this STS service to 79 00:07:54,720 --> 00:07:57,980 manage everything for us. 80 00:07:58,430 --> 00:08:05,520 Cognito user pools allow us to create and maintain a directory of our users 81 00:08:05,520 --> 00:08:10,740 and that could be millions of users, it could be 10 users, or could be anything 82 00:08:10,740 --> 00:08:16,650 but it scales to hundreds of millions of users and those 83 00:08:16,650 --> 00:08:22,680 users will simply be authenticated by signing up and then signing in for your 84 00:08:22,680 --> 00:08:30,090 applications. When it is associated with a Cognito ID pool it can provide secure 85 00:08:30,090 --> 00:08:36,570 access to your AWS resources. So you may have an application that requires access 86 00:08:36,570 --> 00:08:42,930 to some images on Amazon S3. So if that person signs in to a Cognito User Pool 87 00:08:42,930 --> 00:08:49,260 and they're on that user pool, then they will be granted specific access to 88 00:08:49,260 --> 00:08:53,790 that s3 bucket, depending on what is written into that IAM policy that 89 00:08:53,790 --> 00:09:02,000 defines all this. Web identity federation pools they allow you to create unique 90 00:09:02,000 --> 00:09:08,670 identifiers for your end users and those will be kept consistent across 91 00:09:08,670 --> 00:09:15,200 your devices and platforms. So if you log in with a different device it will be 92 00:09:15,200 --> 00:09:21,570 using the same unique identifier depending on despite what device or 93 00:09:21,570 --> 00:09:25,170 platform your login. If you login with Mac and then windows or if you login on 94 00:09:25,170 --> 00:09:29,940 a mobile device, it will still authenticate you as that unique identifier. 95 00:09:29,940 --> 00:09:35,880 So the users can use an identity provider such as Facebook to 96 00:09:35,880 --> 00:09:41,610 log in and then they will attain security token service or STS temporary 97 00:09:41,610 --> 00:09:46,770 credentials. Now one thing I need to say about this is that before Cognito came 98 00:09:46,770 --> 00:09:53,790 along and still now is the case, that you don't need to have Amazon 99 00:09:53,790 --> 00:10:01,170 Cognito to have federated access to AWS resources. Where the Cognito Federation 100 00:10:01,170 --> 00:10:05,730 pools come in or, identity Federation pools come in, is that they will link 101 00:10:05,730 --> 00:10:12,150 that login to a specific Cognito identifier and that can be used with 102 00:10:12,150 --> 00:10:18,750 Cognito user pools or a Cognito sync database as well as for temporary access 103 00:10:18,750 --> 00:10:24,360 to AWS resources. So if we just wanted to have the access to AWS resources 104 00:10:24,360 --> 00:10:32,640 such as an amazon s3 bucket, then you can actually do a federated login using 105 00:10:32,640 --> 00:10:37,590 Google and using the STS service on its own, but you won't have all of the other 106 00:10:37,590 --> 00:10:42,140 features of integrating with Cognito. 107 00:10:42,650 --> 00:10:49,970 Okay so here we've got a one example of how we can use the Federated ID process 108 00:10:49,970 --> 00:10:54,750 So we've got a device here and it has an application running on us on it that 109 00:10:54,750 --> 00:11:01,080 uses the one of the AWS software development kits and we use log in with 110 00:11:01,080 --> 00:11:05,580 Facebook for example and so once we've logged in using that OAUTH process 111 00:11:05,580 --> 00:11:11,400 to login to Facebook, Facebook will give us details of or will give our 112 00:11:11,400 --> 00:11:17,940 application the details of that user such as their account ID for Facebook or 113 00:11:17,940 --> 00:11:22,630 whatever it is and also a security token for Facebook as well. 114 00:11:22,630 --> 00:11:29,230 Once we've got that information we can then use get ID with Amazon Cognito do a 115 00:11:29,230 --> 00:11:36,610 call to Amazon Cognito to get the Amazon Cognito ID of that person that is 116 00:11:36,610 --> 00:11:42,040 logging in with that Facebook account. Once we've got that we can then get the 117 00:11:42,040 --> 00:11:49,630 credentials for that Cognito ID and and get that from the AWS STS service 118 00:11:49,630 --> 00:11:55,420 So we will grab that Facebook token. We will grab the Amazon Cognito ID details and, 119 00:11:55,420 --> 00:12:01,709 we will pass it over to Cognito which will then also pass it over to the AWS 120 00:12:01,709 --> 00:12:08,230 security token service and from there, we will be issued or your application 121 00:12:08,230 --> 00:12:15,399 running on that device will be issued with a temporary AWS STS JSON web token 122 00:12:15,399 --> 00:12:21,850 and from there we use that token to access or have limited access to our AWS 123 00:12:21,850 --> 00:12:25,899 resources. The difference being to the last process that we saw is that we've 124 00:12:25,899 --> 00:12:32,290 got Amazon Cognito here as well, so we can also now with that Cognito ID, 125 00:12:32,290 --> 00:12:42,069 access a Cognito sync database or a Cognito user pool as well. Cognito sync is a key 126 00:12:42,069 --> 00:12:48,060 store database that provides cross device syncing of all of your 127 00:12:48,060 --> 00:12:54,220 application related user data and that will be synchronized across your 128 00:12:54,220 --> 00:12:59,350 multiple devices, multiple platforms, be it windows or mac or whatever and 129 00:12:59,350 --> 00:13:04,930 it also has offline storage. So if you if your internet connection gets cut 130 00:13:04,930 --> 00:13:10,329 you will still have access to that user data. There are two ways of 131 00:13:10,329 --> 00:13:16,120 achieving or accessing this sync key store database. The first one is to use 132 00:13:16,120 --> 00:13:23,170 the Cognito sync manager JavaScript SDK. So that's another SDK that you will need 133 00:13:23,170 --> 00:13:28,120 to load into your your JavaScript application and there is a synchronize 134 00:13:28,120 --> 00:13:31,990 command and what that will do, it will update the records on the keystore 135 00:13:31,990 --> 00:13:36,490 database on the server side and, it will synchronize it with browser local storage 136 00:13:36,490 --> 00:13:43,029 on the device side. Now before the Sync manager came along the 137 00:13:43,029 --> 00:13:47,080 way we did it is that we would do that manually. So we would use the JavaScript 138 00:13:47,080 --> 00:13:52,360 SDK which is another way and use the update records command to update the 139 00:13:52,360 --> 00:13:58,690 records on the keystore database and also to create records if there is no 140 00:13:58,690 --> 00:14:04,300 record there and then we would manually use the browser local storage to secure 141 00:14:04,300 --> 00:14:11,350 that in local storage on your browser, but either way both work but 142 00:14:11,350 --> 00:14:15,700 one of them requires an additional SDK to be loaded into your application which 143 00:14:15,700 --> 00:14:20,620 may reduce the startup time for your application in the browser, so something 144 00:14:20,620 --> 00:14:24,970 to take into consideration, but certainly the Sync manager is a quick and easy way 145 00:14:24,970 --> 00:14:30,850 of doing it. A great thing about using Cognito is that it opens up a world of 146 00:14:30,850 --> 00:14:37,120 really powerful serverless single page applications that are very reactive, 147 00:14:37,120 --> 00:14:43,000 provide very quick feedback to your end-users and use very limited resources 148 00:14:43,000 --> 00:14:46,450 because they're shifting a lot of those resources that you would normally have 149 00:14:46,450 --> 00:14:51,940 on the server side over to the client side. So looking at this example here 150 00:14:51,940 --> 00:14:56,700 we've got a desktop or mobile application and it's a ReactJS application. 151 00:14:56,700 --> 00:15:01,570 So it's going to be a single page application a bit like your Gmail 152 00:15:01,570 --> 00:15:06,250 app in your browser. So it's not going to be doing page refreshes. So anything that 153 00:15:06,250 --> 00:15:10,750 needs to be updated will be updated individually based on what what the 154 00:15:10,750 --> 00:15:14,589 latest information that application is getting and only those components of 155 00:15:14,589 --> 00:15:19,000 that user interface will be updated. So that's going to provide some 156 00:15:19,000 --> 00:15:26,829 really good speed for your application it's also going to shift that work that 157 00:15:26,829 --> 00:15:30,970 would normally be done on the server side over to the client side and that's 158 00:15:30,970 --> 00:15:35,890 going to save you a lot of money. So we already know how to create a single page 159 00:15:35,890 --> 00:15:42,060 application on uploading it to Amazon s3 and using Amazon s3 web hosting and 160 00:15:42,060 --> 00:15:46,390 fronting that with Cloudfront. So we already know how to do that but in our 161 00:15:46,390 --> 00:15:53,499 application we can make calls to Cognito federated ID, we can use a Cognito user 162 00:15:53,499 --> 00:15:59,529 pool or we can use a SAML or OAuth authentication service and that will 163 00:15:59,529 --> 00:16:05,589 allow us to access a Cognito user pool which will keep details on our users. 164 00:16:05,589 --> 00:16:09,489 So that's a great authentication service that is very quick and easy to 165 00:16:09,489 --> 00:16:15,939 set up and you don't have to do that yourself. Now let's say that we want this 166 00:16:15,939 --> 00:16:22,299 end-user to be able to access some data from a DynamoDB database and let's also 167 00:16:22,299 --> 00:16:27,129 say that because ReactJS from Facebook goes hand in hand with 168 00:16:27,129 --> 00:16:33,009 GraphQL which was also developed by Facebook. We might want to have a GraphQL 169 00:16:33,009 --> 00:16:39,249 client running on our application. Now if you don't know what GraphQL is just 170 00:16:39,249 --> 00:16:43,769 Google it because it's another way of thinking about data and it is certainly 171 00:16:43,769 --> 00:16:48,699 revolutionizing the way that we think about integration of data with our 172 00:16:48,699 --> 00:16:53,349 applications so certainly go and Google that and if you are a developer make 173 00:16:53,349 --> 00:16:56,609 sure you know GraphQL because it's going to be here to stay. 174 00:16:56,609 --> 00:17:05,889 So once we've got our client set up they can issue GraphQL queries to AWS 175 00:17:05,889 --> 00:17:12,819 we can set up AWS Appsync which is a GraphQL server and it will provide the glue 176 00:17:12,819 --> 00:17:18,639 between our application and our back-end database and that will be completely 177 00:17:18,639 --> 00:17:25,000 serverless. So here all of a sudden we've got a ReactJS front end, we've got GraphQL 178 00:17:25,000 --> 00:17:32,559 on the client side as a GraphQL client and we've also got federated 179 00:17:32,559 --> 00:17:39,309 identity access to a GraphQL server which will also integrate nicely with 180 00:17:39,309 --> 00:17:45,129 Amazon DynamoDB. We don't have to write any sort of interface between 181 00:17:45,129 --> 00:17:50,860 Appsync and DynamoDB it simply connects directly to DynamoDB 182 00:17:50,860 --> 00:17:56,860 If that DynamoDB database is very popular we can also have a DynamoDB accelerator 183 00:17:56,860 --> 00:18:01,419 which is a cache of our regularly accessed content in a similar way to 184 00:18:01,419 --> 00:18:09,430 cloudfront as a cache for S3. Now let's just say we want to 185 00:18:09,430 --> 00:18:15,100 have ecommerce capabilities for our application, and so to do that we're 186 00:18:15,100 --> 00:18:21,400 going to use the PayPal API. So we need some way of communicating with a PayPal 187 00:18:21,400 --> 00:18:30,760 API and organizing those payments and at the same time updating our database with 188 00:18:30,760 --> 00:18:34,810 those payment details and, what it was actually paid for. So the way we can do 189 00:18:34,810 --> 00:18:40,060 that is that we could implement a Lambda function and so that could communicate 190 00:18:40,060 --> 00:18:47,110 with PayPal API so that whenever a payment is made by a user that is using 191 00:18:47,110 --> 00:18:52,930 this application the PayPal API will notify that Lambda function but 192 00:18:52,930 --> 00:18:57,730 will call an endpoint that will trigger that Lambda function and then that Lambda 193 00:18:57,730 --> 00:19:04,170 function can go back to the Cognito ID service, identify that user and then 194 00:19:04,170 --> 00:19:13,500 update the Dynamodb table with the payment details for that end user. 195 00:19:16,560 --> 00:19:20,500 Okay, so let's have a look at some troubleshooting steps that we can look 196 00:19:20,500 --> 00:19:25,600 at in case we run into some problems. The first one there is if we're hosting our 197 00:19:25,600 --> 00:19:32,770 website on Amazon s3 or using an Amazon s3 bucket and the web hosting service of S3, 198 00:19:32,770 --> 00:19:37,660 we need to make sure that we establish cross-origin resource sharing 199 00:19:37,660 --> 00:19:43,150 or CORS on that bucket otherwise any calls from the application that's 200 00:19:43,150 --> 00:19:49,000 running on that s3 bucket or running on the clients browser, they will 201 00:19:49,000 --> 00:19:56,020 not be allowed by the browser to access that endpoint for Cognito 202 00:19:56,020 --> 00:19:59,950 So you need to make sure that cross-origin resource sharing is set up otherwise 203 00:19:59,950 --> 00:20:05,020 you're not going to be able to access Cognito. You need to make sure that 204 00:20:05,020 --> 00:20:10,840 you've got an IAM role set up for Cognito ID and that there is an allow rule 205 00:20:10,840 --> 00:20:16,030 that allows anyone that assumes that role through a Cognito, that they 206 00:20:16,030 --> 00:20:21,280 have access to that resource, be it for example Dynamodb. So if you're finding 207 00:20:21,280 --> 00:20:25,330 that you're not going to be or you're not able to access that resource after 208 00:20:25,330 --> 00:20:30,670 signing in, make sure that you check that IAM role and make sure that there is an 209 00:20:30,670 --> 00:20:39,310 allow for that service. Now when you set up Cognito ID you need to establish or 210 00:20:39,310 --> 00:20:45,910 define a trust relationship between the Cognito service and that other service 211 00:20:45,910 --> 00:20:49,750 that you're using to authenticate so if you're going to be using an OAuth 212 00:20:49,750 --> 00:20:54,430 service such as Facebook or you're going to be using a Cognito user pool to 213 00:20:54,430 --> 00:20:59,320 authenticate those people or you you might be using a SAML enterprise 214 00:20:59,320 --> 00:21:04,330 service, you need to define that when you're setting up Cognito ID, and that 215 00:21:04,330 --> 00:21:11,080 will allow that trust relationship to be set up by Cognito. Finally you need to 216 00:21:11,080 --> 00:21:16,030 make sure that you're using the correct software development kit for the code. 217 00:21:16,030 --> 00:21:23,950 So there are multiple JavaScript SDKs for this Cognito services, ones for the sync 218 00:21:23,950 --> 00:21:27,760 manager, there's one just specifically for the low-level stuff with the SDK 219 00:21:27,760 --> 00:21:31,840 there's a whole heap of them and you need to make sure that you're using the 220 00:21:31,840 --> 00:21:35,080 right one. So you'll probably start off with the JavaScript SDK 221 00:21:35,080 --> 00:21:41,770 and then you may add the Cognito sync manager SDK to that as well, but you just 222 00:21:41,770 --> 00:21:45,490 need to make sure that, if you're going to be using those commands, that you have 223 00:21:45,490 --> 00:21:51,940 loaded the SDK into your application before you start using those commands. 224 00:21:51,940 --> 00:21:57,370 So that brings us to the end of a very broad overview of the Cognito service 225 00:21:57,370 --> 00:22:02,700 and I look forward to seeing you in the next one.