Is there a way to enforce password expiration policy on users in Amazon Cognito user pools?
It doesn't look like expiration is built into the password policy. You could track password expiration by adding a passwordUpdatedAt field and manually updating that attribute on user sign up and on changePassword. Then you could schedule something that queries users with expired passwords and call AdminResetUserPassword for those users. It would be somewhat more reliable if AWS published Cognito Userpoool User events like changePassword or just baked it into the service.
Related
I am new to AWS Cognito. Based on description, Userpool is used for authentication. If I am a user in the userpool, I can use this user name and password to authenticate my identity. Why do I need to add App to userpool?
Thanks for help in advance,
AWS Cognito allows you to create a number of apps to integrate with your user pool. On each app, you can custom the Authentication flow, Access/Refresh token expiration, attribute read and write permissions, hostUI...
Use case: you use the same user pool for both apps but there are some custom like:
App A: just allow authentication via the ALLOW_USER_PASSWORD_AUTH and access token expiration is 5 minutes.
App B: just allow authentication via the ALLOW_USER_SRP_AUTH and access token expiration is 30 minutes.
Hope that's clear.
I am using the web UI forms provided by Cognito for user sign in to our site with an OAuth flow.
We have a use case where the user should be signed out of all logged in session across browsers.
Looking at the docs, it seems like AdminUserGlobalSignOut does exactly what we're after. However, after calling it the 'cognito' browser cookie saved for foo.auth.us-east-1.amazoncognito.com remains valid. The next time a user loads https://foo.auth.us-east-1.amazoncognito.com/oauth2/authorize they are forwarded to the callback url as if they're authenticated instead of being redirected to foo.auth.us-east-1.amazoncognito.com/login.
I assume this is because the cookie is not invalidated by calling AdminUserGlobalSignOut, however this seems like the exact purpose of this method.
Is this a bug or am I missing something required to log a user out globally?
I know it's kind of too late to answer, but I think this is due to the fact that Token and Cookie are independent of each other.
I think this is expected behavior because the AdminUserGlobalSignOut API is just a feature to revoke Refresh Token, not a feature to invalidate cookies issued by Cognito.
Also, as far as I know, there is no API to disable cookies issued by Cognito. I guess you have to use each Logout Endpoints.
Configuring a User Pool App Client - Amazon Cognito
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html
Important
If you use Hosted UI and setup tokens less than an hour, the end user will be able to get new tokens based on their session cookie which is currently fixed at one hour.
AdminUserGlobalSignOut - Amazon Cognito Identity Provider
https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUserGlobalSignOut.html
Signs out users from all devices, as an administrator. It also invalidates all refresh tokens issued to a user. The user's current access and Id tokens remain valid until their expiry. Access and Id tokens expire one hour after they are issued.
LOGOUT Endpoint - Amazon Cognito
https://docs.aws.amazon.com/cognito/latest/developerguide/logout-endpoint.html
I am looking into using AWS-Cognito as a means to manage and authenticate users. I do not want to use aws api-gateway or any of their other services really. It seems though you can only create roles or policies if they are related to some other aws service. I'd like to have these custom roles or policies on the user's id token returned from Cognito. Is it possible to create these custom roles or policies or am I restricted to only roles and policies related to amazon services? I have found tried the Create your own policy, but it throws an error if it doesn't match a specific action or resource known to aws services. Thanks.
You can use Cognito User Pools to authenticate your users. Then you can call STS to issue temporary credentials based upon your own rules (policies). Look into examples using assumeRole().
If you want an integrated / managed service then use Cognito Federated Identities for authorization and Cognito Users Pools or Google, etc. for authentication.
Sort of confusing, but think of Cognito User Pools (or Facebook, etc.) as the Identity Provider and Cognito Federated Users as the Permissions broker.
We want to allow our users to retrieve a set of temporary CLI credentials for a given AWS role by signing in to OneLogin with password and MFA. We have a working solution, but it requires the user to fully re-authenticate to OneLogin (including MFA) every 60 minutes as the AWS temporary credentials expire. I think that won't fly - our users are accustomed to permanent API credentials tied to a real IAM user.
Ideally, we'd like to allow users to authenticate once a day, securely cache the resulting SAML assertion, and use that to transparently refresh the AWS API credentials as needed. I'm thinking of something like aws-keychain that would use the local OS credential store to remember the SAML assertion, and only prompt the user for input when their OneLogin session has timed out.
This almost works as-is. The catch is that the SAML assertion returned by OneLogin's saml_assertion and verify_factor endpoints sets a three-minute deadline on the Subject and Conditions fields.
Is there a way to do what we want, or are we trying to route around a core SAML principle?
The accepted answer here is no longer true. It is now possible to authenticate the user and verify MFA once at the start of a session and then have the session refreshed on an hourly basis without having to enter further MFA tokens.
To do this you must use the --loop parameter of the CLI tool and have a corresponding App Policy in OneLogin that enables the "Skip if OTP received within last X minutes" setting.
https://developers.onelogin.com/api-docs/1/samples/aws-cli
We're in the process of officially adding an option to in our official CLI tool to re-use the user credentials similarly to what you're describing.
Essentially our CLI tool has an option to reuse the user/pass in the background to continuously refresh the access info in a user profile so while the user will provide credentials once, the access info will get updated before it expires.
But unfortunately, at least at this time, there's no way to get around the MFA part if the application policy requires MFA. It'll need that MFA to refresh the credentials.
If you have to have MFA, you can always use the OneLogin MFA APIs to bake in an MFA flow into the tool...
Check it out here: https://github.com/onelogin/onelogin-aws-cli-assume-role/pull/5
BACKGROUND: Obviously I don't know too much about cognito because I spent the last two hours attempting to authenticate my users with cognito and realized that they weren't authentication providers but rather organizers of credentials.Then I thought of an easier workaround instead of creating a entirely new backend for authenticating users and wanted to verify its viability.
PLAN: I was thinking that I would have users come onto my app and automatically be authenticated with Cognito as an unauthenticated user. Then I would use calls to AWS Lambda and Dynamodb (where my data is stored) and use either a facebookID, which would be obtained from a logged in Facebook user, or a username/password combo to do a basic check and authenticate a user.
Please let me know if any part of my PLAN isn't clear and I will elaborate.
Question: Please let me know if my PLAN is a safe way for me to authenticate users without making an intense backend solely dedicated to creating and storing accounts.
If you want to use Cognito Credentials to access Lambda and DynamoDB, that's exactly the use case Amazon Cognito is meant for.
If you want unauthenticated identities to later on migrate to authenticated with Facebook, note than once you link an identity with Facebook the user will always need to be authenticated to get credentials for that identity: you can't access it as unauthenticated again.