I like to implement the functionality
where if two users are trying to login with the same credentials then the first user should log out as soon as the second user login.
consider user one is logged in with his credentials from one machine
and he/ another user is trying to log in from another machine
then the user one session should be removed as soon as user one logged in.
Ps:
I tried to implement that by saving the current session id in the user table and overriding the OnCreated method from the IAuthSession interface and then checking in that if the request sessionId is the same as the saved session Id if same then process the request else call the lout endpoint.
But It will be not good for performance and I am not sure if it is a good way to do that?
PS: I am using a JWT token.
Update :
I am able to clear the session by using ICacheClient to get the session and then remove a session from the server using IRequest.RemoveSession(sessionId), but is it not log out the specific user.
You can't invalidate a user authenticating with stateless authentication like JWT which has the signed authentication embedded in the Token which is valid until the JWT expiry.
i.e. you can't revoke a JWT Token after it's already been issued.
There is a JwtAuthProvider.ValidateToken filter you can use to execute custom logic to prevent a user from authenticating which you may be able to use however that would require that you manage a collection of Token info you want to prevent from authenticating before its Token expiry.
Related
I've read a bunch of documentation in react-native-firebase, but am not clear about token session works.
Conceptually I think the backend checks if the user session token is valid before accessing certain parts of the database, this means they are signed into their account.
Is this a part of RNFirebase or do we just simply use the 'onAuthStateChanged' method to check if the user is logged in?
How does FusionAuth work if you just completed the Change Password API, tried to re-login using the Login API with the oneTimePassword token, but you have two-factor enabled? Because, from my understanding, it sounds like I would need to interrupt the re-authentication flow for the user to get their two-factor code, after they just changed their password while already being logged in. Is this desired behavior? This line in the docs makes me think this is unintentional:
For this reason, this API will return a oneTimePassword that is intended to be used programatically after a Change Password request completes to keep the user logged in and provide a better user experience. A successful login will return you a new access token (JWT) and a refresh token. This will allow you to make the change password workflow seamless to the user.
I'm using OAuth 2.0 to log in users in my website. Just like any kind of website, e.g. Google, Asana, etc. .
What I would like to know is if there is a way to revoke ONLY the access token and not the refresh token when the user logs out.
This is what I do:
when a user logs in, I create a session and obtain the access token (and the refresh token if the user logs in for the first time). When the user logs out, I just invalidate the session but the access token is still valid.
Sure, the access token will invalidate after a while or when the user logs in the web app again but what I want to know is if the access token can be invalidated during the log out process.
There's no generic answer to this question as the implementation of token revocation behavior wrt. related tokens is Authorization Server specific. Google will invalidate the refresh token together with the access token that is being revoked, other implementations may choose not to do so. Yet other implementations may not even offer a way to revoke access tokens at all.
For Google you can revoke the access token upon logout as described in https://developers.google.com/accounts/docs/OAuth2WebServer#tokenrevoke but it will also revoke the associated refresh token. You must then go through the authorization code flow again to get a new refresh token, which you could try with prompt=none to avoid the user being prompted.
I want to enable Facebook authentication and the FB-Graph in my website, which already has forms authentication. Using http://multitiered.wordpress.com/2010/08/05/getting-started-with-the-facebook-c-sharp-sdk/, I was able to figure out how to login server-side.
However, the problem with this approach is that a secure cookie will not be created, since the call returns the authentication code in the querystring via a callback. This means that the user will have to login every time.
I can see two ways around this:
Store the access token in a secure cookie manually
Instead of the above approach, use the FB JS API to login - this stores a secure cookie with the access token automatically
I would prefer not to use the second approach, as I would like the login code to be server-side.
Which would be the better approach? Am I missing something?
I use the JavaScript method to first authenticate the user, the JS SDK then writes an encrypted cookie (called "fbs_[YourAppID]") when a connected user hits your page; using one of the many Facebook c# SDKs, this cookie can be decoded using your application secret giving you the user ID, oAuth token, expiry date etc.
Then I hook into the AuthenticateRequest event of my .NET application, check the presence of the cookie, decode if it found, and then find a user who has been assigned this facebook ID (your user table must have a extra field for storing the ID of their facebook account).
If a match is found, I write a normal forms authentication cookie for this user, then .NET will recognise them for all future requests. If no user is found, then this is a brand new user who has just connected. Use the SDK again to query the graph API using their oAuth token, get things like their name/email etc and create a new account, then issue a authentication token as normal.
By writing a normal authetication cookie, the user will stay logged into to your site for all requests, just as if they were a normal user.
One side point, when using email address, check for duplicates, and check for the facebook cookie in all requests. For example, an existing registered logged in user may have just connected.
I want to know more about win32 LogonUser api function. The last parameter is a token which can be used to impersonate a windows identity to execute code on a person's behalf. Say I have a login page where I enter my username, password and domain. When the user submits the page I validate the user by making a call to LogonUser() and get a token reference.
I am thinking why not store the token in a cookie and use it at a later stage (perhaps in another page). I just don't know what issues I might have to face upfront...
Can the token expire even if we don't close it properly using the CloseHandle() win32 call? Is there any article related with this particular requirement?