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
Related
I am integrating my client's organization authentication in to one of their web application via ADFS. I integrated the Cognito pool with ADFS and the authentication seem to happen fine. However, I have the following question:
When attempting the fresh login, the ADFS authentication server screen pops up. The user enters the credential and gets redirected to the designated redirect URI.
However, on subsequent attempts the user is not asked for any credentials even after I cleared all the token data from Local Storage. The cookie for the document are also cleared.
Although, this seems like a desired behaviour I would still like to know how it happens. Does Cognito cache some kind of ID data somewhere. I tried searching for something like this but didn't find any related article.
"Does Cognito cache some kind of ID data somewhere"?
No, ADFS does.
There is a client-side cookie and a server-side cookie.
Let's say the ADFS timeout is set to 8 hours.
So you log in the first time, and cookies are created on both sides.
Now on the client-side, the access token expires (assuming OIDC) and the client sends a refresh token. ADFS checks its cookie has not expired and then sends a new access token.
As long as the ADFS side has not expired, you get SSO.
Just for completeness, when you log out, ADFS clears its cookie. When the client-side receives the logout response, it clears its cookie.
Now you have to re-authenticate.
How can I use Google Identity platform as a login / registration system for my own service?
Specifically - how can I do this and support login for same user from different devices?
Using for web service, nodejs without npm modules: passportjs / googleapis / google-auth-library.
My idea:
User opens myClientApp/login page and clicks on GoogleLogIn button which will ask him to authorize my service for specific scopes of his Google account.
I then get the refresh token & access token and save it in DB, then send the refresh token to the client with cookie.
Whenever I make a call to my own service API I send the refresh token from the cookie.
As long as I have valid access token saved in my DB or the refresh token is not expired - I treat the user matching that refresh token as an active session for my service.
Security problems:
cookies attacks, and the refresh token is easily accessed from the browser. Could use https / encryption and more methods to secure the cookie and it's value. Still- someone could copy the cookie from one computer to another!
Multiple login problems:
If the user login on different device, a new refresh token will be created. The previous device the user logged in to will now hold a wrong refresh token in the cookie...
Could the OpenID solve this? Do I need to use JWT?
What is the most secure way to use Google Identity login in my own service while supporting multiple devices login for the same user?
First, make sure that you really understand the security implications for what you want to do.
For example, NEVER send the Refresh Token to a client.
If you want to use the same tokens for the same client on multiple devices, you have a chicken and egg situation. How do you "authenticate" the user at each device. How do you know that user "John" is actually user "John" but on a different device the first time?
Your goal is not to trade convenience for less security. Your goal should always be security first, no matter the inconvenience.
A better approach is to let Google authenticate and authorize a user on each device. They only have to do this once per device. Your backend systems keep track of the Refresh Token issued for each device. You can then generate the Access Tokens and Identity Tokens when needed - they expire after one hour anyways. Store a cookie on the user's device that identifies them to your system so that you can look up who they are, get the Refresh Token, create new Access Tokens, etc.
There is a limit to the number of Refresh Tokens that can be issued before the oldest ones are voided. I think the number is 50. This is usually not a problem. If a Refresh Token is invalid, just put the user back thru the authenticate process and store the new token.
Also provide the user with a sign-out method that removes all stored tokens in your system.
The cookie that you store on the client's devices should be opaque meaning that there is no stored information in the cookie and the cookie is only valid for that device and no other devices. This solves the stolen cookie moved to another device problem.
I will now touch on some of your questions:
My idea: User opens myClientApp/login page and clicks on GoogleLogIn
button which will ask him to authorize my service for specific scopes
of his Google account.
Google OAuth does not work that way. You send the user to a URL, Google manages all display and input with the end user. Once everything is complete a callback URL on your server is called and you are passed a code. The exact details depend on the type of OAuth Flow that you are using.
I then get the refresh token & access token and save it in DB, then
send the refresh token to the client with cookie.
During the OAuth Flow you will request the Access Token, Refresh Token and Identity Token. The Refresh Token is saved in the database. Never send this token to the client. Read my suggestion above about creating an opaque cookie that you send to the client.
Security problems: cookies attacks, and the refresh token is easily
accessed from the browser. Could use https / encryption and more
methods to secure the cookie and it's value. Still- someone could copy
the cookie from one computer to another!
Create an opaque cookie that is only valid for that device and no other devices. If a client sends you a cookie intended for a different device, consider this a problem and invalidate all cookies, tokens, etc for this user on all devices.
Multiple login problems: If the user login on different device, a new
refresh token will be created. The previous device the user logged in
to will now hold a wrong refresh token in the cookie...
I covered this issue above. Store the Refresh Token generated for each device in your DB. Consider each device / Refresh Token / cookie as a set.
Could the OpenID solve this? Do I need to use JWT? What is the most
secure way to use Google Identity login in my own service while
supporting multiple devices login for the same user?
By Open ID I think you mean Open ID Connect (OIDC). This is already integrated into Google OAuth and this is the part that generates the Identity Token.
Do I need to use JWT?
Google OAuth Tokens are generated from Signed JWTs. However for the most part you do not need to worry about the format of tokens. Google provides endpoints that validate and decode Google OAuth tokens.
What is the most secure way to use Google Identity login in my own
service while supporting multiple devices login for the same user?
I covered this question in the first part of my answer above.
I'm quite new to AWS Cognito and about token security. I decided to use AWS Cognito for may application. I followed the guide here for my web app and my web api.
https://dzone.com/articles/identity-as-a-service-idaas-aws-cognito-and-aspnet
https://dzone.com/articles/identity-as-a-service-idaas-asp-net-core-api-and-a
Everything works fine. But when I try to create a new User pool in AWS Cognito and then change the appsetting for both web app and web api to use the new user pool, I found something quite weird.
(For the web app). User still can access controller action by the old token that belong to the old User pool that used before even the action is marked as [Authorize]. I don't know why user still can access with the old token even appsetting is set to the new User pool. (But User cannot access to the web api,that use new User pool, with the old token)
(For both web app and web api). Then I deleted that User from the old User pool and set web app and web api to use the old user pool. I found that User still can access both action in web app and web api even that User was deleted.
I think that it might be something that I missing about validation token or setting. Can anyone suggest about a solution to fix that?
The ID Token issued by AWS Cognito User Pool is a JWT token, which is Signed By AWS. Once issued the token is valid for 1 hour. Within this 1 hour, there is no way of revoking the token since its stateless.
Amazon Cognito generates two RSA key pairs for each user pool. The
private key of each pair is used to sign the respective ID token or
access token. The public keys are made available at an address in this
format:
https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json
Since the public key is publically available, anyone can verify whether the JWT token is authentic and issued by AWS Cognito.
However, this involved multiple things to verify.
Validate the JWT Token Encoding whether its compliant with JWT standard.
Validate JWT Issuer, whether its the particular User Pool (Verify its ID).
Validate whether the token is an ID Token (Optional).
Validate the Audience of the Token (Whether it is issued for the particular App).
Validate Token Signature (This is where the public key is needed).
Validate whether the token is expired or not.
This information is already self-contained within the JWT token string properly encoded according to the JWT standard.
Therefore, even the Cognito User Pool is deleted, if there is a valid token (< 1 hour after issued), it should be valid, if the verification process uses a stored Public key to verify it.
From what I understand, the end-result of the implicit flow is the access token, which allows the client (in my case a JS SPA) to authenticate into resource servers (APIs).
The access token is usually only valid for ~1 hour, then it expires - making it useless.
What should my JS app do then? Redirecting the user back to the auth server is unrealistic since then the user will have to reenter their credentials every 1 hour!
I also know that the implicit flow doesn't support refresh tokens so I can't use those either.
Is there a way to persist the user's login? How do things like Facebook keep you logged-in indefinitely?
Just to clarify, you are asking about the Implicit flow which is detailed in the OAuth 2.0 RFC rather than OpenID Connect which deals more with authentication of a user?
With the implicit flow you do have to regularly call the authorisation endpoint to obtain a new token, but if the user remains logged into their identity provider then they should not be prompted to resubmit their credentials, and the token will be returned as a hash fragment in the redirect uri, with no user interaction required.
You can use an AJAX call to get the token on a back-channel so your SPA app user experience is not affected by the need to get new tokens.
To address the points you highlight in your question:
The access token is usually only valid for ~1 hour, then it expires -
making it useless.
Correct!
then the user will have to reenter their credentials every 1 hour!
Not necessarily.
If the user stays logged into the identity provider (e.g. facebook, google) then there will be a browser cookie between the user and that provider. This effectively means the identity provider does not need the user to re-enter credentials. The authorisation server should be able to return you a token with no interaction required.
Is there a way to persist the user's login?
You can't control it from your SPA. It's totally dependent on the user staying logged onto the identity provider. If they stay logged into facebook, google (or whatever IDP you app uses) then you should be able to get tokens non-interactively.
This article nicely explains how the implicit flow can be implemented.
If the session at the OP is still active (via a cookie perhaps), then OpenID Connect has a mechanism to refresh tokens in a (hidden) iframe: prompt=none.
According to the spec, when sending this flow...
The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if an End-User is not already authenticated or the Client does not have pre-configured consent for the requested Claims or does not fulfill other conditions for processing the request. The error code will typically be login_required, interaction_required, or another code defined in Section 3.1.2.6. This can be used as a method to check for existing authentication and/or consent.
prompt=none is also referred to from the Session Management specification.
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