47. Evaluating AWS Cognito For Your Architecture

Rich: In episode 47 of Mobycast, we take a high level look at AWS Cognito and discuss when it’s a good option for your projects. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. Let’s jump right in.

Jon: Welcome, Chris and Rich. It’s another episode of Mobycast.

Chris: Hey.

Rich: Hi guys.

Jon: Hey, good to have you here. We have a lot to talk about today. I have an appointment to do some yoga which is part of my 2019 New Year’s resolution to get a little bit more flexible. I was convinced to do yoga by my friend, Eric, who lives in California. He said he got a half inch taller from doing yoga. I said, “That’s all you had to say,” so here I am doing yoga.

Chris: I forgot to tell you that the next morning when he wakes up, he’s a half inch shorter again until the next yoga session.

Jon: Right. Anyway, I’m doing that but I got to get out of here pretty soon. We got to skip other intros and get right into what we’re talking about this week which is AWS Cognito. AWS Cognito has been around for a few years now. I think two and three years ago, I remember doing some research as to whether to use it for mobile apps that we were building for a couple of different clients. I looked at it twice, maybe three times. This was before Chris and I were working very closely together. It maybe was more like three to four years ago. Time flies when you’re not doing yoga.

When I looked at it before, I felt like it was really similar to this other service that’s not been sunsetted in called parse.com. I thought, “Yeah, this is kind of like Parse, but it’s way harder to use.” I really don’t understand this documentation very well. Yeah, maybe it looks a little bit more powerful but for this mobile app we’re building, we don’t need that power. We just need to get users logged in and store some data alongside that, just really, really simple backends for slightly above brochure-style applications.

When you don’t need a full-on backend but you do need to let users access particular content or store little pieces of data that relate to them, services like Parse and Firebase were good options. Cognito felt like not a good option. So, that brings us here today and just last week, we talked about the serverless application that I’ve been building with the serverless architecture using Lambda and a few other things including Cognito.

In this experience, I’ve come to learn more about Cognito, get over that initial learning curve which is fairly steep, and come to realize that it’s really pretty cool and pretty powerful. I thought we can talk more about it today. Just a quick definition of what it is, Cognito provides user authentication and management services. It’s kind of like a managed micro service that gives you the ability to make users and then gives you the ability to create sessions for those users. Log them in and log them out, or create them, and update them with their email addresses, verify their email addresses, things like that.

It just lets you create users, but then the other big thing it does, and this is the thing that I think a few years ago I was like, “Meh. That’s not important to me,” but it’s really important now, is the ability to do federated identity management, which is a fancy word for being able to connect those users through sort of an intermediary shadow user to AWS services. Being able to connect them directly and authenticate them for using S3, or DynamoDB, or specific Lambda functions, or really any AWS service, whatsoever. Now, with so many available serverless, managed services from AWS and the ability to create applications, kind of in an IKEA style or Lego blocks style, this becomes super powerful.

Before we talk more about exactly what Cognito does, let’s kind of back up and let Chris talk for a second about building user systems, user microservices, and typical web-based applications today. How are we doing this for some of our other clients, Chris, and what are the expectations of those services?

Chris: For any kind of application whether it be a mobile app, or a web app, or even kind of a backend app, authentication usually is pretty important. Understanding the identity of the caller and authenticating that it is indeed that caller, and then managing permissions based on that identity, is very fundamental to any kind of system that you’re building. There’s many different ways to do that. You could go and roll your own, which we’ve definitely done in the past. You can use other identity providers/services. There’s many folks out there in the space. You have folks like Off Zero, you have companies like OneLogin, there’s Okta, there’s many more.

They provide the kind of single sign-on capabilities, identity management, users, and it works across a range of apps. A lot of times, those ones work a lot better for web and backend, and sometimes it’s more difficult to work with mobile clients. For us, most of the software that we write needs authentication. It’s going against our own backend application servers. That ends up becoming kind of the integration point. Typically we’ll use something like roll your own, or usually more frequently, we’ll leverage one of these other identity services. It allows us to have an identity pool, a directory of all the users in the system. We can attach permissions and roles on those users and then have authentication go through that system to identify them as that particular user, and then we have the attributes now associated with that. That usually gets passed along. Something like a JWT, a JSON web token, or something like that that we can then unpack and inspect when we receive the request on the backend.

Jon: One of the things you mentioned is roles and I think the roles that you’re talking about are roles that you define yourself that then you in your application code can check against to give users the abilities to do things or not, right?

Chris: Yes. It’s like, this user has the normal user access. They have the user role. And then, maybe someone else is the administrator, so they’re going to have an admin role-type thing. When I mention roles, it’s really from the context of like a suite of permissions that lights up.

Jon: Right and it’s specifically a suite of permissions that are contextually related to your application that you’re building. If your application lets you upload files, then that would be something that you would write some code that would go, ask Off Zero, or Okta, or OneLogin, “Hey, does this user have the role that lets them upload files,” and then OneLogin would say, “Yes,” or “No,” right?

Chris: Yeah. Absolutely.

Jon: Those are just typical requirements of the user identity management system. That’s exactly what Cognito provides, too. I think it used to be really kind of mobile-only, really, really geared for mobile users, so that it was very easy to set up. It had specific SDKs that you could drop into your iOS applications or your android applications that let you just run, call code that knows how to talk to Cognito without writing any HTTP requests or anything like that.

From that perspective, I think a few years ago, Cognito did a poor job of competing with OneLogin, or Off Zero in the web world. I think it may be catching up. There’s two reasons that it may be catching up. The first, let’s just talk a little bit about the federated identity capabilities that it brings. These days, you have a lot of services that you’re using. If you’re doing AWS solutions architecture where you’re really using a lot of different AWS cloud services, then you may be using S3, Lambda, Dynamo, RDS, so many different services. Each of those services is connected into AWS’s policy system and IAM system essentially, IAM service and so is Cognito’s.

The way that Cognito breaks things down is when you create a federated identity pool. You tell the federated identity pool, “Here’s two roles I want you to use. This is the role I want you to use when the users logged in, and this is the role I want you to use when users are not logged in,” and then based on those two roles you can say, if a user’s logged in, they can upload stuff, they can add things to the table. If they’re not logged in, maybe they have certain read only types of permissions, or just zero permissions to these Lambda functions, but some to these other Lambda functions, things like that.

It’s really clear what users can do when they’re run through that federated identity pool. The only thing that’s a little abstract and weird is that you have two different pools. One is called your user pool and that’s more akin to the features and functionality of OneLogin or Off Zero. I think of it more classically as your user table. It’s got your users in it, it’s got their passwords, their emails, and all that stuff. That’s the user pool. The federated identity pool also does create a little ID per user, but it can be connected to one or more user pools. That’s the tricky part. You can say, “Hey, this federated identity pool is connected to a Cognito user pool, a Google user pool, a Facebook user pool,” and basically, all of these identity providers can be the backing store of users to talk to the federated identity provider pool.

Basically, it’s acting as like a middle man between those identities and the AWS services. The way that we set it up in this little app that we’ve been building, we just only use Cognito as the identity pool, as the user pool, and then the federated identical pool points to Cognito. Everybody that’s logged-in via Cognito then becomes a logged in user according to the federated identity pool, and therefore gets logged-in user access roles for the various things that they access. In this case, that’s S3, Dynamo, Lambda, and API gateway for the most part.

This is the key. This all sounds complicated but when you actually go to implement it, then it becomes very, very simple, and then you start to feel the power of it. While I feel like I’m kind of saying a lot of things here and it’s like, “Oh my God, how did I learn all this as a developer?” there’s not that much work you have to do and what you get for free is, for example, a private directory inside an S3 bucket that only the person who matches that federated identity gets the right to read from.

If you’re creating a document store and you want users to have a little private area for them to store their own documents and you want to really make sure that no other users are going to see those documents, it’s a lot less code to write to be able to just use Cognito and say, “Hey, this Cognito federated identity is the only one that gets to write to and read from this particular folder inside this bucket, without any additional set up.” You’re not configuring EML files, you’re not configuring JSON, you’re just connecting the Cognito identity pool to the bucket. That’s really pretty powerful. I think it gets into some visibility, this cool new thing that I’m learning about with Cognito. This gets into kind of the next question of when would you use Cognito? When does it make sense? Chris, I think you can take this away from the point of view of clients talking directly to AWS.

Chris: Yes. I think maybe one of the ways I think of Cognito is just a couple of components. You have basically a list of users at your user pool, and then you have a list of mapping those users to things that they can do, roles or permission, and that’s the identity pool.

Jon: Inside of AWS. Right, those roles are not the same as your application roles that we talked about earlier. They are really AWS roles.

Chris: Right. This is Cognito. It’s basically like, “Hey, I have a list of users somewhere,” that list of users can either be inside Cognito itself through its user pool, or you can federate to other sources like Facebook, Google, whatnot. For those users, you can have this mapping. This is now an IAM role like what permissions do they have and then now given that, they can go access those AWS services. They can go access S3, or they can go access API gateway, or Lambda, or Dynamo even.

This is what Cognito is really good at and it’s really suited for. If you are building applications where you have your frontend clients, whether they be web or mobile clients, you’re kind of completely serverless and you’re just talking to other managed services inside AWS, then Cognito is something you want to look really hard at. This is the perfect use case for it. If your app is built with things like API gateway, and Lambda, and Dynamo, you have to have a really good reason not to use Cognito.

Jon: I would even say that React apps, like if you’re talking directly to S3 buckets, especially if you’re doing a lot of that, that sort of gets pretty interesting because then you can avoid the whole signed URLs thing. There’s one piece I left out. You can talk directly to the S3 bucket. There is one the whole thing that glues all this together which is AWS Amplify. That’s essentially just the SDK. It’s essentially just a JavaScript library, or an iOS library, or an internet library that lets you do three things: authentication, storage, and API. The storage in this case is S3, the authentication is Cognito, and the API is Lambda, or API gateway.

Using methods and functions inside AWS Amplify, that’s what gives you a lot of that special sauce. It gives you a lot of the ability to log in, have a session all of a sudden, AWS Amplify just dropped a cookie or something like that into your React app, and then that now when you make calls to upload a bucket to S3, you’ve got a session going with Cognito and S3 is like, “Oh, I know who you are, you’re a Cognito user. Yeah, come on in,” without doing signed URLs. It’s like a secondary service that’s not your actual application.

Now that I’ve fully interrupted you and taken the whole conversation over AWS Amplify, let’s bring it back to what you were just saying which is, why would you not look at Cognito if you’ve got clients that are speaking directly to AWS services? Any other points to add to that, or is that just the thing? That’s the one thing to make the decision on whether to use it?

Chris: I think if your clients are making requests directly to AWS managed services, then Cognito is definitely something to look at. That’s really what it’s like up here. There’s many different ways to integrate something like S3 into your application and there’s various techniques. You could do things. Like I said, you can have signed URLs to get temporary access basically through a temporary role essentially. You could do things like proxying through the backend, so the actual permission to do that writing to S3 is coming from your backend services and entity.

You may decide for other reasons like you want your clients to talk directly to the S3 buckets themselves underneath that particular user’s identity. It just really depends on what your application architecture is. The core thing here is that if you want your application talking directly to managed AWS services, then definitely look at Cognito.

Jon: I think that’s a pretty simple advice, I think it’s sound in terms of building applications that are cloud-native and use AWS’s services to sort of solutions architecture away. I think as a company, we’ll definitely be looking for this same exact opportunities going forward.

Chris: Yeah, absolutely. Maybe just on a parting note to get into just to subtle difference like maybe answering the question, why we haven’t used Cognito all that much? It’s because we use serverless where it makes sense, we’re using Lambda where it makes sense, but for the most part, we still have micro services running inside containers on ECS. We’re going through load balancers. We could use Cognito but it would end up probably being a bit more work because we would have to deal with the federated identities, having them work with our services as opposed to something that we’re used to working with, whether it be something like OneLogin, or Off Zero, or something else. That’s one of the big reasons why it just hasn’t lit up a lot of scenarios for us just because of the architecture that we have.

Jon: Yeah, makes sense. I think we are looking for more opportunities to use some of these managed services that have become hotter and hotter in the last couple of years from AWS. It probably is going to happen, but I do agree. The upside of AWS services is always their integratedness. They’re always so carefully coupled but also carefully decoupled with other AWS services, and that makes some really powerful use of development scenarios.

But the other thing is, each individual service on its own when compared to its competitors, a lot of times does have a bigger, steeper learning curve. Just more cognitive overhead to take it on than its competitors that are really streamlined and really purpose-built to do one thing, and not to be integrated to 100 other things.

Well, thank you very much, Rich and Chris. It was great to talk to you about Cognito today.

Chris: Thanks guys.

Rich: Thanks.

Jon: We’ll see you next week for another episode.

Rich: Well dear listener, you made it to the end. We appreciate your time and invite you to continue the conversation with us online. This episode, along with the show notes and other valuable resources is available at mobycast.fm/47. If you have any questions or additional insights, we encourage you to leave us a comment there. Thank you and we’ll see you again next week.