I'm using FormsAuthentication mechanizm and auth users via
FormsAuthentication.SetAuthCookie(...);
Can I logout current user from all browsers somehow?
Add a guid parameter inside to authentication parameters. Also save guid to a session table for example like this;
public class sessionLog
{
public int UserID { get;set;}
public string Guid {get;set;}
// ... may be you can add IP, datetime or isSessionClosed etc
}
When login add a row into table, save guid inside the cookie.
Check the user authentication with userID and guid is enabled.
Remove row logout with the guid or remove all with userID for close all sessions.
Technically, that's impossible. The user is authenticated via an encrypted cookie set within the browser. Logging the user out merely invalidates that cookie. There's no way to then invalidate cookies that may exist in other browsers or even other machines.
The only way you could potentially achieve something like this is to indicate in some way, tied to the user's account, that they have been logged out. This could be an additional column on your profile table or some other type of persistent storage medium. Whatever you do, you would then need to look at this when an authenticated user accesses some portion of your site. If they have been previously logged out, you would then log them out again on that browser/machine instance. When they log in again, you would clear whatever you previously set, so that they would remain authenticated. In other words, you have to check and invalidate the auth cookie in each browser when the user attempts to access the site from that browser. There's no way to do anything until the user accesses your site from that particular browser.
You need to store a list of users logged in on an application variable. If a user with that Guid tries to login again you can display a message that they are already logged in elsewhere....
I don't think you can control users session once it has been granted, but you could add logic to deny access to functionality if an attempt to login from elsewhere (I'm not sure why you would want to do it though because logging in from different devices is not always done maliciously).
Related
Using Identity Serve 4 with .Net Core 3.1, razor pages. Also using Cookie Authentication
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
Problem -
In a web application John logged-in 2 times
1st Login on Chrome
2nd Login on edge
So, if John again trying to logged-in on 3rd time on Firefox without logout from previous browsers, then I want to logout John from 1st Login on Chrome forcefully.
I can keep the track of logins in a Session table including Session Id, User Id etc.
But I don’t know how logout user from a particular session using Session Id.
Please help.
Thanks
ASP.NET Core provides an ITicketStore interface which allows you to get control of storing user sessions. Once you provide a class implementing this interface and register it, it will call your class when sessions are being created or verified which you can then store in a database however you like, including attaching arbitrary metadata like browser ID etc.
Now that you have user sessions in your database, you can separately query them and revoke as needed in other logic, including during logins. Since you now provide the session data, simply deleting the record effectively logs the user out from that session. Note that if you use any caching layer to reduce the store requests, you'd need to remove any cached copies as well.
Note that this is separate from IdentityServer and happens with ASP.NET Core itself.
This is a good tutorial that helped me implementing this in my app.
A sample of how it looks to register in Startup, where PersistentTicketStore is my implementation:
// Persistent ticket/cookie store to provide durable user sessions
services.AddSingleton<IUserSessionRepository, UserSessionRepository>();
services.AddSingleton<ITicketStore, PersistentTicketStore>();
services.AddOptions<CookieAuthenticationOptions>(CookieAuthenticationDefaults.AuthenticationScheme)
.Configure<ITicketStore>((options, store) => options.SessionStore = store);
Use the End Session Endpoint
The end session endpoint can be used to end a session and trigger a log out
In the log in process you will need to capture the id_token received from authentication and what user it belongs and store it on some dbo.table. You can use this same table to also keep track if a user has logged in more than once.
To log out a user or end a session you will need to pass the ID you saved as a query string parameter called id_token_hint in a GET call as shown below into:
GET /connect/endsession?id_token_hint={id_token}
For reference see the documentation here https://identityserver4.readthedocs.io/en/latest/endpoints/endsession.html#end-session-endpoint
Since you're saying you can keep track of logins, perhaps you should keep track of each session and assign a number somewhere indicating when it was logged in (1 for Chrome, 2 for edge, 3 for Firefox).
Then each time a request is made, you check in your table what the lowest number is (1,2,3 etc), and if the session matches that number, you sign the user out from that session.
await
HttpContext.SignOutAsync(IdentityServerConstants.DefaultCookieAuthenticationScheme);
Since each browser will have their own cookie, you can use the above method.
After signing someone out, the next login can be assigned 4, and if 2 makes a request you log that client out.....
Also see this: https://github.com/IdentityServer/IdentityServer4/issues/736
I have implemented this.
When a user logs in, the session id (IUserSession.GetSessionIdAsync) is manually stored in our database. The previous value of this database field is used to create a logout_token which I send to my clients. You can have look at IdentityServer4.Infrastructure.BackChannelLogoutClient to figure out how to create the token and post.
All this assumes you have backchannel logout implemented ofcourse.
I am using Identity Server 4 with the quickstart UI and a client using Cookie Authentication.
Lets say I have user A on machine A who is currently logged in via the browser. Then user A decides to go on machine B and logs into that one. As it stands, a new session cookie will be issued for user A on machine B as well as machine A.
This is fine, but I want the option to mark particular users with a flag e.g. IsConcurrent and if it is set to true, they will be given the option to either keep their existing session on machine A, or terminate it and start a new session on machine B.
I have done some reading and found references here to updating the security stamp for a user and setting the interval to zero, so it checks the security stamp in the cookie against the stored version. However, this code didn't seem to be inline with Identity Server's code. Also, it it a valid option in this case?
I also found here which mentions storing and checking the value of session IDs, but I'm not sure if this is valid either?
An initial idea was to implement some middleware that obtained the Machine ID and stored it in a table along with the user, but then I was unsure how to take something like this any further.
Any help or advice would be much appreciated.
Assuming cookie based authentication, you can extend the client to validate the user session provided that the client keeps track of user sessions.
For that you can create a session manager where you add a session for the user (sub) after login, this also includes automatic login sessions (SSO). Remove one or all sessions on logout, which should also be updated on back channel logout (LogoutCallback).
Assuming you use middleware, you can consult the session manager there and decide what to do. Make sure that the current session isn't already activated after login. It has to step through the middleware at least once. Some pseudo code to illustrate the idea:
public Task Invoke(HttpContext context, SessionManager sessionManager)
{
if (context.Principal.Identity.IsAuthenticated)
{
var sub = context.Principal.FindFirst("sub")?.Value;
var sid = context.Principal.FindFirst("sid")?.Value;
// User is allowed when the current session is active.
if (!sessionManager.CurrentSessionIsActive(sub, sid))
{
// Rewrite path if user needs and is allowed to choose: redirect to session selector or
// Activate the current session and deactivate other sessions, if any.
if (sessionManager.HasMultipleSessions(sub) && sessionManager.CanSelectSession(sub))
context.Request.Path = new PathString("/SelectSession");
else
sessionManager.ActivateCurrentSession(sub, sid);
}
}
return _next(context);
}
On post of the SelectSession form you can mark in the session manager which sessions are active. If the old session should be preserved, then ignore the old session (remains active) and mark the current session as active.
Make sure to add the middleware after authenticating the user.
Please note that for access tokens you'll need a different strategy.
I logged in as user 1. and user2 in another browser. I have a user identity session value in cookie. when i copy user1 cookie value and paste it in user2 cookie value user 2 got changed to user1 . How to prevent this?
You cannot prevent exactly this behaviour. That means if someone gets a token to represent a user (a cookie in your case) then he can represent that user. This is called session-hijacking. Think of it as someone finding a key to another house, it's not much preventing that person from entering the house even though it's not his.
It is possible to do some workarounds that big sites like google do: check if it's a new location or a new computer and ask for additional validation for example, but it's probably not a simple feature.
Otherwise you need to protect your tokens as best as you can to prevent them being accessible in an easy way, like suggested in comments by using TLS, having HTTP-olny cookie that cannot be read by javascript, etc, ensuring proper logout that will delete the cookie and so on.
I'm working on a project with Asp.Net MVC 5 and Asp.Net Identity and I'm using two factor authentication. For the login I use:
var result = await SignInManager.TwoFactorSignInAsync(model.Provider, model.Code, isPersistent: model.RememberMe, rememberBrowser: model.RememberBrowser);
which is the default code that came with the new project. However, I also need the ability for a user to "trust" or "remember" a browser, similar to how banks can indicate if this was the first time you have signed in from a particular browser/pc.
My question is around the RememberBrowser property on the sign in method and what .NET Identity does with this data. I want the list of saved browsers and the ability to revoke access to one/and-or all of them. Is that possible within the Identity framework? Also, can I tell if a browser has been "trusted" before by some type of lookup?
Edit:
Maybe it's a good idea to save the browser info in the database and check on login instead of the cookie? That way it can be shown as a list with the ability to delete it. What I'm looking for is what to save and how to integrate it with the Asp.Net Identity without having a security risk.
Edit 2
Here's an example from a website that is already using this:
Edit 3
Maybe this can be implemented as another step for authentication. So basically we'll have a 3 factor authentication:
First user logs in with user/pass
Then we'll check if the 2FA is enabled and get the code if necessary
We get the user's aser agent and IP and check the database if it's new. Then notify if necessary.
So I'm guessing an new cookie should be added to save browser's info. However, we should be able to invalidate this cookie along with the 2FA cookie.
RememberBrowser sets a cookie that allows the 2FA step to be skipped. There is no central way to track this though it would be easy enough to log, however the results may not be accurate because people can delete cookies manually. There's no way to invalidate it I believe but it doesn't really matter as you can invalidate their session and the user is will be required to login with their password again.
Not sure whether saving browser info adds value as browser info is gonna be same for different users (using same browser and version) unless you save requestor IP as well; and saving requestor IP has too many complications.
How about adding a custom claim to the token if user has set RememberBrowser and then do your logic based on this custom claim? For eg, set a custom claim your_claim_name and set a Guid.NewGuid() to it if RememberBrowser is true. Also save the username, this guid and status flag in database . When a request comes, check whether your custom claim is present, if yes query the table with the custom claim value and username to check whether the entry is still active.
You can either delete the entry or soft delete (set the status) the entry for an user so that when next request comes you can perform your required logic.
I have implemented ASP.Net Identity after following the sample code here:
https://github.com/rustd/AspnetIdentitySample
In my implementation I check if a user is authenticated - this is called from a FilterAttribute on my MVC Controllers; the idea is i want to confirm they are still auth'ed before serving up the page.
So in my filter, the following code eventually gets called:
_authenticationManager.User.Identity.IsAuthenticated;
_authenticationManager is here:
private IAuthenticationManager _authenticationManager
{
get
{
return _httpContext.GetOwinContext().Authentication;
}
}
The _httpContext is passed into the constructor of my identityProvider class.
Now - once I have logged in, _authenticationManager.User.Identity.IsAuthenticated; returns true as expected.
However, during development, i dumped and re-seeded my database, without adding a user. So effectively, I have deleted the IdentityUser - yet _authenticationManager.User.Identity.IsAuthenticated; STILL returns true
any idea why this is? I can only assume it's somehow checking a cookie, rather than actually looking at the DB. is this correct?
Or have i messed up my implementation.....
This does not make IsAuthenticated a security hole. Let's look at the actual authentication process.
You setup some stuff in your web.config around where the login page is, how long the login is good for and whether or not to use sliding expiration (should the time be extended if the user is active on your site)
User comes to your site, enters their username and password.
That information is posted to your server. You take that information, verify that it is correct (authenticate). If it is correct, the server then issues an encrypted cookie known as the FormsAuthenticationTicket Note - this could have a different name in the new Identity stuff, but the same principle.
The cookie's contents includes items such as the user name and expiration date of the login.
On each request, the server looks at the cookie collection for the authentication cookie. If found, it decrypts it, reads the values and determines if this is still a valid cookie (expiration time). Once it has the user information from the cookie, the server can use this information to determine if the user is authorized for the resource requested (look up by username).
5a. If the cookie is not present, or has expired, then the user is redirected back to the login page.
6.When the user logs out, the cookie is deleted from the cookie collection. Now, if the user tries to go to a resource that is for authorized users only, then the server ends up at 5a above.
So, in your case, you deleted a user manually. This does not change the fact that this user has previously been authenticated with a still valid cookie. Therefore, IsAuthenticated is returning the expected value. The user has authenticated before you changed his user status. IsAuthenticated does not mean, is this user still valid in my database.
If you are going to be running a site where you are constantly deleting/deactivating users, then override the OnRequestAuthorization method of the AuthorizeAttribute to look and see if the user is actually still in the database. Also, note that if the username is not present (because you deleted it), then any look ups for role / userId will fail. You can catch that exception / failure and return the property unauthorized response.