I am building an expo app that leverages auth0 for authentication.
I have trouble switching to another account after I have successfully logged in and logged out. The details reproduce steps are:
Pull the project, yarn install && expo start --ios
(Optional) For your safety, replace auth0ClientId and auth0Domain in App.js with your own auth0 info
Press "Log in with Auth0", get a prompt, and finally see something like below
Log in with gmail (there should be such an option, even though it is not in this picture)
If you successfully log in, you should be able to see "You are logged in, !"
Press "Log out"
If you try to redo step 3-4, you are no longer able to see the universal login page as shown in the picture. Instead, you are logged in directly.
This thread describes the same behavior but he assumes it is client that caches the authentication info in cookie. I don't think this is the reason. I believe auth0 caches the first logged in user on server side and return the cached result regardless. My evidence: I add this console.log at https://github.com/ocdexperience/auth0-example/blob/master/App.js#L68 and every time I try to log in, this line always print that's why I guess await AuthSession.startAsync({ authUrl }) returns the cached result directly.
Thank you for the help.
It sounds like you are being logged in via silent authentication. This does indeed use a session cookie. To fully logout the user you must clear the cookie, or use the recommended method of utilizing the /logout endpoint.
You can test this by logging in with an incognito/private browsing window, or by clearing the cookie before clicking the login button the second time.
Related
The flashing system basically makes it possible to record a message at
the end of a request and access it on the next (and only the next)
request
Please can I have an example wherein a msg recorded at the end of a request will need to be accessed in the next request?
flashing is very useful for websites.
Let's say you have a login system on your website and you want to notify user after they logout, then you can simply add a flash message saying something like "You have been logged out!"
Everything works fine without flashing but it gives extra confirmation to the user and makes website more user-friendly.
I am having trouble logging out of my identityServer under Google login. I can login through Google (external) with no issues but the logout never worked. After clicking on "Logout" I always get a message says "you are now logged out". But when I try to log back in again, I always get right in after clicking on the Googol button. My Chrome's Dev Tool shows that a cookie associated with my Google login left in there regardless if I click on logout.
And if I clear the cookie via Chrome, I will be able to get to the Google login page.
In trying to delete the cookie in my program when logging out, I tried the following code from the AccountController's Logout function. I watched the code got executed in debug mode, but it doesn't make any difference - the cookie is still there after the code gets executed and I am still get right in.
Could anyone tell me what I am missing here? Or is it just impossible to delete cookie from code?
To do an upstream signout the IDP (Google) would have to support the RP-initiated logout spec:
https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout
However Google's discovery endpoint (https://accounts.google.com/.well-known/openid-configuration) does not advertise an end_session_endpoint so from that we'd have to conclude that it is not supported by Google.
However you may be able to use prompt=login or max_age={number of seconds} in your authorization_endpoint endpoint request to force interactive authentication again. When you receive the id_token in the callback you can validate that the auth_time claim falls within whatever condition you decide. The end result is that you can insist that users interactively authenticate each time you do a round trip to Google. If auth_time is too far in the past you'd prevent the local session from being established.
We have React Native app that uses Cognito for authentication. We would like to prevent the same user ID from logging in simultaneously from multiple devices.
We were hopefully that we could use a Cognito pre-authentication trigger for this. Unfortunately it seems that we can't just call globalSignOut for the user since that wouldn't invalidate tokens that have already been issued and are currently active (see https://github.com/amazon-archives/amazon-cognito-identity-js/issues/21#issuecomment-331472144).
The other idea was to reject the login if the user is logged in elsewhere. But we can't see a reliable way to tell whether the user is already logged in. We can see if there are valid tokens issued for that user but not if they are currently associated with an active session.
We also thought of maintaining our own DB of active sessions but there is no sign-out trigger so we wouldn't know when to remove a session from the DB.
You can use a token authentication system,
Issue a brand new token for each login, and check for available tokens.
if any token is available for the user that means He/She is logged in some other device, for this case you can prompt user that You are logged in other device.. are you sure you want to log out from that device ? and after clicking yes, you can clear all tokens for that user. And issue a brand new token.
AUTO LOGOUT : this token should be passed all over the back-end i.e. in headers of each and every API call token should be there... and should be checked before doing anything in back-end. if token is not available then throw 401. In your app if any API throws 401 then it means user is UNAUTHORIZED and should be logged out.
or
your app should be listening to one socket that responds to log out when it receives a message of same. so whenever your user logs in, a logout message will be passed across sockets and appropriate device with some token id or unique id will get that message and will log out a particular user from all other devices.
or
have a notification receiver which will be used to log out whenever necessary same as socket.
Reading the link you provided the API token / session system seems being faulty by design since long time already.
So without an own token-system inside cognito you won't have reliable results probably, at least in the current state of the system (as the repository is archived it won't be developed further by the owner).
What I propose is an own field in the database-table for users where each login is honored with an own token. A second own field in the same table with a timestamp, where the last access is saved.
If last access is older than a predefined time of 30, 60 or 120 minutes any user gets logged out.
If the last access is younger than the time-limit then the login-mask has to provide a random access token which is compared with that in the database:
- if the access-token in the database is too old for an active session, or just no access-token is stored, then access can be granted which means login is successful.
- the comparison of the current time with the time-stamp saved in the database is for cases where users never have been logged out by purpose but just by being disconnected or passive. I think this case will happen regularly, so it's no exception.
- logging out by click on a button should destroy the access-token in the database, so that the user can immediately login from any device, even from another one then before.
- if there exists a valid access-token in the database then no new access will be granted and the user should get shown a message that he has to sign out first at another login.
- The access-token could be stored together with a third own field for the session-id to make it more reliable and safe. On logout that session-token-field can be cleared too. The session-token can be copied from the global session if required to be saved in the user-record.
- Any checks are only done on login, tokens never have to be included on every page.
- On active logout the token(s) have to be destroyed to allow a direct login again, else the users had to wait till the max. age of the time-limit is reached to login again - at least on another device then before.
As the login itself is currently done independent from the check that has to be implemented, it would be possible to leave the new access-token completely away but use only the session-id as that differs on any device and browser. But perhaps there exists a situation where one of session-id and access-token can change but the other one not - I don't think so but perhaps I missed something in my considerations.
If you provide the access-token on every page like proposed by #Jadeep Galani or in a cookie - beside the corresponding check - you also can offer a button to sign out from all devices. This would enable the users to change login any time even without logging out at the last used device. Without access-token on every page or in a cookie this general logout-function solution is not possible as else access is only checked on login but not on all pages.
A general question is if it's still worth it to rely on the buggy cognito for login or just replace it completely by an own solution. You even could implement the desired authentication in your site in form of a wrapper-class and the concrete login-system could be replaced without changing that implementation.
You can use the UUID of the device to identify whether it is the same user. Add a UUID to each request header to record it in the DB, and then you can do what you want.
Here at my company, we started using Ping Federate as our Identity provider, this is linked with the AD for user info and so on.
The login works via the OAuth page, and this works great, I can login, do things, then when my access_tokenexpires this get's refreshed and I can continue without the user even noticing it.
But now I got the request of one of the users if he could switch logins.
but this isn't possible, because when I click login, the popup of PingFederate that get's fired doesn't asks for the credentials, it just continues and uses the last credentials.
However when i clean my cookies and I login it asks for the credentials again, but I can't ask the users to clear all it's cookies whenever he wants to switch users.
I tried clearing the cookies of the PingFederate Domain when I logout, but no luck:
me.$cookies.remove('PF', {domain: 'federation.xxx.com'});
any body else has an idea what I can do to make this work?
You should be able to use PingFederate's logout features to achieve what you're after.
If you're using just the HTML Form Adapter to log in users, then you can configure a logout path in your adapter instance that you can ask users to go to to logout. See "Logout Path" here: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=ttq1564003023121.html
Alternatively you could enable single logout (SLO) which will trigger a logout at all adapters or other authentication sources the user may have logged in to. For more details, see:
https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=php1564002958041.html
https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=pqn1564002990312.html
I'm new with Jmeter and by default sorry for dump question.
I want to start with the most basic testing for web site. I want to login to application and navigate to specific page. Basically, that is it for now.
I was fighting with this issue but unfortunately I cannot save cookies properly. I use the following test scenario:
However, after I start to run scenario I can see that login was executed successfully, but navigation on page redirect to Login page.
It seems that cookies were not actually saved.
Please any advice. If you require any additional information I'll provide everything what is needed.
What makes you say login did not work or work ?
Why don't you first look in View Results Tree at first "Http Request login" sampler response to check that login was successful ?
To see if Cookies are transmitted check Request Tab in View Results Tree to see if Cookies are transmitted.
From what you show it seems you are playing login twice, check your Thread Group for number of iterations ? if you set more than 1, maybe your application does not allow double login.