I have an application (node.js) that need an Authentication and authorization.
My app need access to postgres database and also need a Inheritances (roles etc.)
One option to implement that is using the cognito service of aws (the app will host on aws properly - not sure about that)
so the questions is
Is cognito service support the authorization for node.js with database that is not services on aws? (I read that "identity pool" is for aws services like mariaDB)
If my app will be on heroku (not on aws), I will also be able to use with cognito services (for authorization)?
Is cognito support roles/users inheritances ?
Tnx
Cognito identity pool is used for granting access to aws services. User pool is used to exchange user credentials for tokens which can contain additional information about the user once decoded. So yes, you can use user pool just for authentication. Your user attributes can contain information related to the services this user needs to access.
However, if you plan on storing database credentials, I suggest you use AWS secrets manager to store your DB credentials and grant the cognito user access to this secret. You'll need to use both user pool and identity pool in this case.
Not directly, but you can use it to access secrets manager where you db credentials are stored.
Yes you can use cognito anywhere. It will be connecting to AWS to grant you tokens however. And these tokens are only recognized on AWS. Which is why you need to use them to access other secrets that can be used to access whatever other services you want.
Cognito supports groups. I'm not sure if that's what you mean by inheritences. You can have token based roles with groups.
I'm developing a mobile app that must access some AWS resources, so it needs authentication to AWS endpoint. The app doesn't manage users (sign-in, sign-out, register and so on).
My first solution was to create a IAM user dedicated to the mobile app and embed its credentials in the mobile app code. The app authenticate itself to AWS using the embedded credentials. It works, however AWS suggests to avoid embedding credentials directly in the app.
I think a better solution is Cognito. Because I don't need users management, I should use unauthenticated (guest) identity to request temporary AWS credentials.
However I don't understand why a guest Cognito identity is more secure than an embedded credentials. The mobile app receive a temporary AWS credentials by sending a Cognito Identity Pool ID, that is a long-term "number" embedded in the mobile app. If someone is able to find this Identity Pool ID, she can receive AWS credentials and access AWS resources as my official mobile app. It seems there's no difference between embedded AWS long-term credentials and huest Cognito access.
Why Cognito solution is better than embedded AWS credentials?
If you are creating unauthenticated access using identity pool, you are allowing public to access your AWS resources. Make sure you write your policy carefully and it won't matter if you use a single IAM user or cognito unauthenticated access as far as security is concerned.
Using federated identity will provide you benefits like getting statistics on usage and adding triggers to events. Also keep in mind that creating a single IAM user and then allowing multiple people to use these credentials is a "hack" way of doing what cognito federated unauthenticated idenity was designed to do. You might run into unexpected complications later if AWS decides to throttle this behavior of IAM.
I don't understand auth. vs. unauth. user access within AWS Cognito. While learning about Cognito I came across several articles on the Internet and questions here within Stackoverflow concerning this and I'm just not grasping the concept.
I'm gathering that a simple use case for unauth. user access within Cognito is when we have users who need to access some AWS resource(s) who have an account but aren't "logged-in." But how is this possible? In other to get an access token, wouldn't you need a valid username and password? If by unauth. we mean a user who has a valid access token but can't access some resources [based on some user pool parameter], I suppose that makes sense, but I don't understand how Cognito works in this regard.
I've searched for hours on this w/o grasping this concept and I really just need a little help from the community if anyone would be willing to share.
UPDATE: What's confusing to me is that "unauth." is a non-logged in user already, no? Why do I have to or want to get an access-token for a non-logged in user? What is the purpose of this?
Something that is confusing when starting out with AWS Cognito, is that it is actually two services. Cognito User Pools is a user store that authenticates users and Cognito Identity Pools authorizes users.
Unauth:
When referring to a unauthenticated flow, you're skipping the authentication process and really just authorizing with an identity pool. To do this in code, you setup a credentials provider, and make a call to GetID. This generates an identityID in the identity pool and retrieves authorization tokens that give access based on the IAM role for unauthenticated users. Example here
Auth:
Now for the authenticated flow, before you authorize with the identity pool, you have to have authentication tokens. These can be retrieved by authenticating with a third party (Facebook for example), or with a Cognito User Pool. You authenticate with those services by providing a username/email and a password. The tokens delivered by those services can then be "passed" to a credentials provider. When done this way, authorizing with the identity pool will return access tokens that give access based on the IAM role for authenticated users. In addition, a user can "log out" and later "log back in" and they will be able to receive the same identity ID that was generated for them the first time they authorized with the identity pool.
I hope that all makes sense. I'll give an example of why you may combine the two
Example
Let's say we're building a web platform that lists events around our city. This platform needs to:
Store events in a database
Allow city organizers to add events to the database
Allow residents to view the events
We wouldn't want the residents to have to login to view publicly listed events, so when they visit the event's page of our website, unknown to them, they actually authorize with an identity pool. Thus they are provided unauth IAM role access to make a GET API call to our database, to retrieve the events.
Of course, we don't want just anyone adding events to the database. So for city organizers, there is a login form. This login form takes a username and password to authenticate them with a user pool. The user pool tokens are then used to authorize with the identity pool, giving them auth IAM role access to make a POST call to our API, allowing them to add events to our database.
We're building an application using AWS App Sync, we're still in a very early stage.
Our application has a restricted area, through user sign-in, which is being managed via aws cognito users pool. And this is fine.
We're having issues on the public area which doesn't require any authentication.
How can we protect these public endpoints?
We're having some doubts about hard coding the api key (that we know can be rotated), is it a good practice (documentation page says that it isn't ideal for production)?
Is there any way to authorise the origin? (aka, any request coming from www.foobar.baz is ok)
I would suggest using Amazon Cognito Federated Identity to control authenticated and unauthenticated access to the api. In order to do use Amazon Cognito Federated Identity with AWS AppSync, you need to use AWS IAM based authorization.
For the authenticated access you can use Amazon Cognito User Pools and federated to Amazon Cognito Federated Identity and since the federated identity can also allow for unauthenticated users it will allow you to control some api's which can be made public via an IAM policy.
For more information please read the AWS IAM Section of our security guide here
Under your AppSync app's Settings menu, where you set the User Pool Configuration, there is an option to set a default action. You can change this to DENY and all unauthenticated requests will be rejected. The alternative approach is to ALLOW everything, and manually add #aws_auth directives to every query/mutation/subscription field that you care about restricting.
AWS provides cognito which provides the developer with sign-up and sign-in functionality including federations with OpenId compatible identity providers such as facebook, google etc.
There are two types of categories in cognito developer console. These are managing user pool and managing federated identities.
I'm just a little bit confused because both are very similar even we want to provide our client to login with their facebook account.
The cognito user pool itself provides federation and federation identity pool also provide it by authentication providers.
The question is that if I want to allow my clients to use their own facebook account for sign-in, which categories should I use? user pool or federated identities?
In addition, if I want to configure authorizer in API gateway I have to create cognito user pool but federated identity pool. Is that the main reason choosing the cognito category?
Cognito user pool:
Amazon Cognito User Pool makes it easy for developers to add sign-up
and sign-in functionality to web and mobile applications. It serves as
your own identity provider to maintain a user directory. It supports
user registration and sign-in, as well as provisioning identity tokens
for signed-in users.
Cognito Federated Identities or Identity Pool:
Cognito Identity Pool (or Cognito Federated Identities) on the other
hand is a way to authorize your users to use the various AWS services.
Say you wanted to allow a user to have access to your S3 bucket so
that they could upload a file; you could specify that while creating
an Identity Pool. And to create these levels of access, the Identity
Pool has its own concept of an identity (or user). The source of these
identities (or users) could be a Cognito User Pool or even Facebook or
Google.
Relationship between User pool and Identity pool:
The Cognito Identity Pool simply takes all the identity providers and puts them together (federates them). And with all of this it can now give your users secure access to your AWS services, regardless of where they come from.
So in summary, the Cognito User Pool stores all the users which then plugs into Cognito Identity Pool which can give the users access to AWS services.
source
You can think of user pools as sort of a directory which contains user attributes such as name, email, phone number etc. This also provides sign up, sign in capability. You can federate users into user pools. Currently you can use Facebook, Google, and SAML as identity providers for user pools.
Cognito Federated identities lets you federate users into AWS and vends AWS credentials that can be used to access the resources you allow in your policy. For Cognito Federated Identities, you also have a variety of identity providers that you can configure such as Facebook, Google, and also Cognito User Pools can be an identity provider.
What you use depends on your use case. If you don't require AWS resources for your app, probably User Pools is all you need.
I believe AWS should separate User Pool and Identity Pool, and change the names. Because mixing up different services under the same name causes confusions, and the names do not give any clue about the services.
User Pool -> AWS Authentication and Token vending service, similar to Auth0. You can use Auth0 instead of unnecessarily complicated User Pool
Identity Pool -> AWS IAM Authorization service for the authentication tokens such as Auth0 token or AWS JWT token (from User Pool)
An analogy would be:
Use Pool is an agency in your country that identifies who you are and issues a VISA (The VISA is the token which the Identity Provider provides you as a user).
Identity Pool is the border control of the foreign country called "AWS" that you visit with the VISA. They verify who you are with the VISA and authorize what you can do in there. If the border control does not recognize the VISA, you cannot do anything. If they recognize it, then they have fine grained rules defined for each VISA what actions are allowed and where.
Forget about User Pool
Better focus on Identity Pool. Because User Pool is just another Identity Provider service like MSAD, Google, Facebook, Auth0, etc. An Identity Provider authenticates and provides a token e.g. Kerberos Token for a MS AD users, or a Cognito Userpool JWT token for a AWS Cognito Userpool user. Then Identity Pool can utilize the token to authorize access to AWS resources.
AWS has been mixing up this Identity Provider/Authentication service with Identity Pool/Authorization service, besides their strange naming, hence causing massive confusions, incurring the questions.
The name "Identity Pool" does not make any sense as it has no indication on what the service does. A word must navigate thinking that leads to understanding, not confusion. AWS exactly does the opposite.
Preparation
Before jumping to what Identity Pool does/is, better to understand a few things.
AWS STS Token
Naively saying, AWS STS Token allow us to create, use, update, delete AWS resources programmatically.
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN
If you have an AWS account user, you can get AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for the user, and then get a STS token using e.g. MFA.
IAM Role
In reality, an IAM Role defines which actions allowed on which AWS resources for a STS token. It may not allow delete but create. So it depends on the IAM Role what a STS Token allows us to do.
However, the point to note is, there is a association between an IAM Role and a STS Token you get, and someone must define the association for you.
What Identity Pool gives you
It gives a STS Token, using which you can manipulate AWS resources in an AWS account.
Situation where Identity Pool is useful
Another problem of AWS for me is their documentation does not declare This is when you need Identity Pool, but instead keep repeating the word Federation which does not point to what Identity Pool does, allow you to manipulate AWS resources with a STS Token.
If you are in the situation where:
I want to manipulate AWS resources in an AWS account, and
I do not have an AWS IAM User (or I do not want to use it), but
I have an account in Corporate AD, or in Google, or in Facebook, or in Auth0, or ..., or in Cognito User Pool.
Then you can use Identity Pool to get a STS token for the account e.g Google you logged in, and can manipulate the AWS resource.
For instance, if you have 1000+ users in your corporate AD and want to let them use AWS resources somehow. Would you create 1000+ AWS IAM users? Or find a way to map them to a few IAM roles such as "Administrator", "Accounting", "Finance", "IT"?
What Identity Pool does
Identity Pool maps an Identity Provider token (e.g. Google token) to an IAM Role in an AWS account, and gives a STS Token.
AWS calls this "mapping" as Federation, in my understanding.
I would recommend completely forgetting User Pool when discussing Identity Pool. User Pool is just another Identity Provider which you may not need at all.
Likewise, when discussing User Pool, I would recommend completely forgetting Identity Pool.
I do hope AWS will separate Identity Provider Service (User Pool) from Token Mapping service (Identity Pool) to stop causing confusions.
The best summary I have ever heard is:
user pools return JSON Web Tokens (JWTs) which are used to access APIs that you built (using api gateway or appsync)
identity pools return Security Token Service (STS) tokens that are used to access APIs that aws built (s3, dynamodb, etc.)
Watch this cognito deep dive video for more details.
The below picture is a good answer to the question (User pool Vs Identity Pool)