👀
Main aim of this article is to write about my understanding of AWS Cognito. Although this blog won’t have comments section, I’m always reading my email so feel free to drop me one if you feel I’ve gone off the rails with this one.
It’s an authentication and authorization service. What’s the difference ? Well, authentication authenticates, authorization authorizes.
What I mean is, if you sign in with your username and password, you authenticate yourself into the system.This means the system agrees you are a valid identity, but not necessarily one that is authorized to access certain parts of it. Authorization is your permission to see or access certain parts of the system you’re authenticated into.
There are two main parts of Cognito, one is User Pools, the other is Federated Identities.
User Pools handles authentication. It supports pretty much everything you can think of, sign up, sign in with or without third party services (Facebook, Google, Amazon etc.), multi-factor authentication, message verification, analytics and it can be scaled with lambda triggers.
Any successful signin attempt with User Pools provides tokens that you can use either to gain access in your server side app, gain access to AWS API Gateway or exchange them for temporary AWS Credentials to gain access to AWS Services.
One importand part of User Pools is the App Client. Think of the App Client as the access point for the data stored in User Pools. Without creating one, you won’t be able to authenticate.
App Client has predefined access rights to User Pool data, e.g. a list of user attributes that can be read or written during the authentication process, information about the refresh token expiry time, an App ID (generated by Cognito) and and optional APP Secret (also generated by Cognito).
Why the trouble? Well, user pools can have multiple app clients and each App Client can be configured with different access levels to that data. If you think of similarities with Facebook Developer Apps then you would be right.
token
is actually tokens
because it actually generates three of them and the information encoded inside these tokens is, in fact, controlled by the App Client:
-
Federated Identities handles authorization inside AWS. This component stores identity data in identity pools and doesn’t support authentication, therefore it relies on separate authentication providers that can be anything from an already created User Pool to Facebook, Google+(until Google closes it down that is ) or SAML and even a custom authentication provider.
What this means is that another authentication provider will issue a token, like User Pools for example, then Federated Identities consumes that token and exchanges it with AWS Credentials which, in turn, provide access to AWS Services.
This is only an introduction about the general workings of AWS Cognito and the next articles will, in fact, create some exercises and solve them. As time passes by and AWS launches certain parts of Cognito (like Analytics) in all available regions, this service will become more and more mature and staying on top of it might prove useful.