I have read the AWS Amplify API and I have found some weird thing.
I've found 2 similar functions
currentAuthenticatedUser() and currentUserPoolUser().
They have the same description, parameters, and returns.
I want to know why they separated.
[reference]
https://aws-amplify.github.io/amplify-js/api/classes/authclass.html#currentauthenticateduser
https://aws-amplify.github.io/amplify-js/api/classes/authclass.html#currentuserpooluser
I believe user pool users are those that are from Cognito, whereas an authenticated user is one that come from an identity pool (from a federated identity).
See: https://aws.amazon.com/premiumsupport/knowledge-center/cognito-user-pools-identity-pools/
From the code, it looks like currentAuthenticatedUser checks for federation info. However, if it doesn't find federation info, it just calls currentUserPoolUser. So I'd say call currentUserPoolUser if you know you're never going to be using federated logins, but you should probably call currentAuthenticatedUser if there's a chance you might.
according to amplify auth docs, both result in "A promise resolves to current authenticated CognitoUser if success"
Related
There is some ambiguity in the docs...
These docs seem to imply that pre-signup is called only during signup and first-time (?) external provider login. The only trigger source constants mentioned are:
PreSignUp_SignUp
PreSignUp_AdminCreateUser
PreSignUp_ExternalProvider
However, the ForgotPassword doc mentions calling it as well:
When you use the ForgotPassword API action, Amazon Cognito invokes any functions that are assigned to the following triggers: pre sign-up, custom message, and user migration.
In general is there a definitive, accurate source of what Cognito Lambdas are called for which user/api actions?
Below is AWS's response to my comment on their docs page. In short pre-sign-up is NOT run on ForgotPassword.
We recently received feedback from you about the following page in the
Cognito documentation:
https://docs.aws.amazon.com/en_us/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html
Your comments were:
What I'm trying to do: ...
What to make better: Does InitiateAuth trigger pre-signup? Its a bit
ambiguous in the ClientMetadata section. Really each of these docs
should have a section on lambdas invoked or better, a chart of how and
when (for instance, ForgetPW is a three part process - when are the
various lambdas invoked??)
I'm sorry that you're having difficulty finding the information you
need. The sources for Pre sign-up triggers are listed at link [1]. The
function runs when you run the SignUp and AdminCreateUser APIs, as
well as when you sign in for the first time using an external
provider. The triggers that you can run on InitiateAuth are Pre
Authentication, Post authentication, Define/Create/Verify custom auth,
pre token generation, custom message, and migrate user.
Link [1] also describes the triggers associated with a ForgotPassword
process. You can run post confirmation, pre token, migrate user, and
custom message functions.
Thanks for taking the time to send us feedback! We appreciate all
feedback, whether it's positive or it alerts us to a problem we need
to address. Please don't hesitate to contact us with any other
feedback you might have about our documentation.
[1] Customizing user pool workflows with Lambda triggers - User pool Lambda trigger sources - https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools-working-with-aws-lambda-triggers.html#cognito-user-identity-pools-working-with-aws-lambda-trigger-sources
I want to implement a blog API - for fun and learning - which allows a user to manage and write/view their own blog posts. So far I have an API with paths like
/ - GET all posts,
/blog/{id} - GET a specific post or PUT to update a post
/blog/ - POST for a new blog
Using a cognito user pool, a user can sign up, and login and the API Gateway uses an authorizer to allow or deny access (I'm mucking about with Blazor at the same time - there isn't really an interface yet just a bit of cobbled together C# that uses the identity provide API}.
However, any user can see all posts. I really want something like this:
/{user}/ - GET all posts by user
/{user}/blog/{id} - GET or PUT specific blog post
and so on.
Behind the API gateway are four really simply lambda functions. So far, with the user pool authorizer I can see the Authorization header but nothing else (the request context and context have no Identity elements that are not null).
I was wondering whether I could use Identity Pool to do the specific user permissions using IAM Roles, but I cant think of what the roles might look like, or whether this seems possible. I know there are parameters you can embed in roles - you do that for S3 Roles - why not API paths?
Does this sound plausible or would I need to go down the Lambda function to do authorization? Anyone any examples? I googled and look through stack overflow, but couldn't see anything specific around this.
Another problem I guess would be getting a nice ID substitution for user here - I collect email and nickname so far - need a nice username rather than a cognito user id, which looks like they're wouldn't play well with a URL?
Thanks.
The answer to my query appears to be in this you tube video, put up by the AWS team late last night (uk time, anyway.) So far, using C#, I can authenticate myself against the user pool, and get AWS Credentials, but when I attempt to access my API I get "message": "unauthorized", and that's it!
Anyway, onwards and upwards.
You tube video about fine grained access control using cognito identity pools.
I am currently switching from IBM APIC to AWS API Gateway. I found a different behaviour that it's not detailed in the AWS documentation (https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)
After i use the refresh_token to get a new access_token i have a different behavior:
In IBM the initial access_token is invalidated.
In AWS you can call the API with the initial access_token and with the "new" access_token.
Is there an option to invalidate the initial access_token when the refresh_token is used?
Thanks.
So I think what you're seeing here is that old token is still valid, in short no you can't invalidate it UNLESS you call global sign out. I think the minimum time a token takes to expire 60 minutes.
Cognito has some flaws still really, listUsers API doesn't search by custom attributes, if you use federated identities you can't retrospectively link by email as you've found the token implementation isn't quite ideal yet.
I have a Cognito Identity Pool that is used to authenticate my front end users, as well as give them certain permissions in my application. However, I have encountered an issue with giving these users permission to access IoT, which involves invoking a Lambda calling iot.addPrincipalPolicy(), and once that is done then everything works flawlessly.
However, the issue I am facing is that right now I am running this function is being called every time my user requests authentication, when it really only needs to be ran when the user signs up. Is there a way to make sure that it only gets ran once? I was thinking of using a Cognito User Pool trigger, but that will only work for my users who authenticate with Cognito and not with Facebook or Google.
So basically, I would like to only call this function once, the first time that the user gets an Identity Pool ID. Is there a way I can do this that will work for all login methods?
As I don't have enough rep points to simply put a comment, I will leave this here just in case it helps you.
Cognito User Pool recently gained support for Facebook and Google identity providers, so you COULD user a User pool trigger if needed.
http://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-social.html
I'm currently exploring the AWS stack and am therefore building a simple web app. I plan on using:
S3 to host the static contents
DynamoDB to store user data
Lambda + API Gateway for backend logic
Cognito Federated Identities to authenticate users
I currently have a small tracer bullet application working that allows the user to authenticate with Google (through Cognito) and retrieve some data through a Lambda from DynamoDB. Now I want to extend it.
The next thing I want to do (and am failing to achieve) is to actually store the user name and e-mail of the authenticated user. Storing it shouldn't be a big problem, but retrieving it is. I know I initially got the data from Google because when I inspect the ID token (on JWT.io) I got from Google, I can clearly see my e-mail and name. This is the token I sent to AWS Cognito in exchange for a Cognito token.
I was expecting to be able to access this data again in my Lambda function, but I fail to figure out how actually. I understand Cognito performs a one way hash on the retrieved ID token, but I would expect some options to actually retrieve relevant user data from the token. After all, by authentication through Google (or any other IdP) a user already consented to sharing some personal data.
I feel I fail to see something obvious. Is there any feature in AWS that solves this? Is there a moment (not on the client side) where I can inspect the ID token and do some magic with it? Or should I solve this in some different way?
If the latter is the case: what would be the preferred way? I don't want users to tell me their personal data, because then I would also need some way to validate it.