ITRavels

👀

AWS Cognito - Introduction

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.

What is Cognito ?

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.

How does Cognito work ?

There are two main parts of Cognito, one is User Pools, the other is Federated Identities.

  1. User Pools
    • 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.

    • When User Pool generates token upon a successful authentication, that 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: -
      • - ID Token will only contain user attributes the App Client has access to
      • - Access Token will only contain information about the level of access the user is entitled to (think authorization)
      • - Refresh Token contains information about how to refresh the previous two tokens
    • All three tokens are JWT tokens and if you feel like digging more about it, or even find out about libraries that can decode these tokens, feel free to read this and this.
  2. Federated Identities
    • 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 :scream:) 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.

    • I think the best way to understand Federated Identities is consider an example. Let’s presume we have a Dropbox like application that doesn’t really care about keeping user information and uses Facebook Login to authenticate users then lets them upload files in S3. -
      • - So what do we know about authentication of this exercise ? It’s a third party authentication, therefore no need to use AWS User Pools, the authentication provider in this case is Facebook.
      • - What do we know about authorization ? Well, our app needs to authorize access to AWS S3, therefore an AWS Service.
    • Every time you need direct access to an AWS Service you should think of Federated Identities.

Conclusion

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.