AWS Cognito
Amazon Cognito is a technology that lets app developers implement user sign-up, sign-in and role based access control in web and mobile applications to support serverless authentication and authorization, and when using federated identity, can act as identity broker.
Note RBAC is implemented when users are divided into groups and each group is then provided different permissions
Practical Example, Streaming Platforms can use AWS cognito to let users sign-up and sign-in through Google or Microsoft Accounts or Apple ID and different users would have different viewing permissions to the content the streaming platform will host based on if a user is on ad-supported free tier model or paid premium subscriber.
Identity Sources in Cognito:
Simply speaking, they represents the source of authentication or user pool.
User Pool Directory - It leverages Cognito itself as identity source and managing user directory by using cognito user pool that stores identity information (username and password), user profile information (photo, URLs etc), compatible with AWS Lambda as well as supports categorization of users into groups
Identity Federation - It enables users to sign-in with an existing identity source (enterprise, social) (Example: Sign in with MSFT AD, Sign in with Google etc)
Identity Pools - It enables to grant users access to other AWS services. Note this can be used in conjunction with user pool or even separately. Use cases - Direct service integration (client apps use aws direct creds of the service to integrate and communicate with AWS services) and Permission pass-through (it can be AWS Lamda function or other functions that uses the permissions of the user and not the function itself)
Authentication flow:
History and typical use case of AWS Cognito
Previously, the web application tier would be divided into client and server where upon authentication, server would provide cookies to client and subsequent requests would be interacted with that session cookie. Usually the application logic was mainly on server side and client used to only display rendered output.
This got changed to API based architecture, where the application logic or main heavy lifting shifted to client side and only required data would be fetched from server. So app clients would communicate with API tier on server i.e., instead of web requests, API requests (which can be said as standalone functions) would be made and based on data received, app at client side can display output. Now, instead of session cookie, the better solution that was implemented would be to use either use OIDC standard via JWT tokens or Cognito User Pool. Either OIDC that allows third party identity providers such as Google, Facebook, Microsoft etc or Cognito User pools allows to authenticate and provide user profile back in those JWTs (this is what actually replaces session cookies and information is provided back and forth into JWT components which are trusted due to the it being digitally signed).
Note JWTs have 3 components: first one is HEADER shows token type and algo, the second one being PAYLOAD has the main part where data about the user and its relevant profile is present and last component is the SIGNATURE part. There are basically three types of JWTs at play, which are ID Token (Contains user identity info), Access Token (Contains groups and scopes) and Refresh Token (Used to get new ID and access tokens), which are obtained upon successful authentication and validity of these tokens can be changed and is mostly configured inside Cognito user Pool .
It is these access tokens that is used to access resources in AWS. The validity of a token can be verified whether it is for specified user pool (iss), whether the client_id is valid, whether toke is not expired, whether token is not expired(exp), whether is time is in past (iat), verifies the token scope, verifies the signature with the user pool keys.
So, how this works is that once authentication happens, let's just say using Cognito user pool, all three JWT tokens are received, which will be sent in future API requests.
To make this more meaningful, IAM roles can be created that has access to specific AWS services like S3, so whoever assumes the role can access the required resources and these IAM roles are then mapped to Identity pool. So the authentication flows works like that first do authentication and obtain JWT tokens. Using the access tokens, which on user basis, can obtain short term credentials for particular AWS IAM role, which can then be used to obtain resources from other AWS services like S3
Creating User Pool
Creating Identity Pool
Last updated
