I'm using MVC 5 default template with "Individual Accounts" selected for authentication. it uses ASP .NET Identity with Entity Framework.
Using Chrome I opened the app and Registered a user and then login with the user. I accidentally deleted the database. Now when I open the app again in Chrome it still shows me signed in since auth cookie persists in browser. However the user that is logged in doesn't exists in the database.
Is it the correct behavior?If not then any suggestions on how to prevent it?
That's correct behaviour. As long as the auth cookie is valid and not expired your app assumes the user is authenticated.
When you disable or (soft) delete a user, you should call UserManager.UpdateSecurityStamp(string userId) which causes the auth cookie to be invalid on next check.
Related
I have a web application with singe factor authorization and now have implemented two-factor authorization. I am using the Microsoft Identity for the log-in. The problem is - so far we have used a cookie to remember the user while providing the username and password. Say that as 'signglefactorcookie'. Now on the authenticator application authorization page(TFA), I have added another cookie for the remember me option. Say that as 'twofactorcookie'. Now how can I make my client request for both cookies when I use the below code?
// Check whether there is a valid session or persistent cookie
if(this.User.Identity.IsAuthenticated){
// Move to a landing page
}
Problem scenario
Now the problem is, if I log in to the single-factor authentication page with the correct user name and password and land at the two-factor authentication page.
Open a new tab and try to access the home page getting success since there is a single factor cookie that is recognized which makes the user authorized.
How can I make it in a standard way?
I am using identityserver4 for all configured clients with "AccesssTokenType=1" i.e. reference type.
I have one web app hosted for server, and other one for clients.
I used default identityserver settings, which generated two cookie, one for session Id "idsrv.session", and other one for authentication "idsrv".
In logout I do signout
await HttpContext.SignOutAsync(IdentityServerConstants.ExternalCookieAuthenticationScheme);
await HttpContext.SignOutAsync(IdentityServerConstants.DefaultCookieAuthenticationScheme);
however it gives error when I call with "idsrv.session"
await HttpContext.SignOutAsync(IdentityServerConstants.DefaultCheckSessionCookieName);
Issue / Steps to reproduce the problem
1st Iteration : Login on my client website which redirects to my identityserver application. I now interceprt the request and response using "Burp Suite". I copy the complete response which has redirect URL's and cookie details.
I signout/logout from client website.
2nd Iteration : I tried login again, and intercepted the request and response using Burp Suite, by passing wrong credential. While Intercepting the response I just copied the cookies from previous request (which was successful in my first iteration), and observe that identityserver has successfully validated the user using the cookie value, ignoring the wrong credentials in this iteration.
Even I tried invalidating and deleting cookies in my signout/logout method, but looks like identityserver still recognises it as the valid ones.
Brock Allen directed me to the corrrect solution. According to him :
This is the real issue you're asking about -- when you signout, you want the cookie to no longer be valid, even in the scenario when it's stolen and replayed. This is not something IdentityServer can address, because we use Microsoft's cookie authentication to achieve signin. You would have to fix this by changing the default usage of their component. You can do it by implementing "server-side cookie" (a term that I dislike) by implementing an ITicketStore: https://github.com/aspnet/Security/blob/master/src/Microsoft.AspNetCore.Authentication.Cookies/CookieAuthenticationOptions.cs#L136
Details Here
https://github.com/IdentityServer/IdentityServer4/issues/2565
Currently, I am using ID4, asp.net core and angular 2. Everything works well but I am facing one issue, when we open many tabs on browser. Then, we logout on one tab but other tabs still keep token and call API successfully. Can we force or validate token and return to login page on all tabs?
My code to sign out on server
await _signInManager.SignOutAsync();
HttpContext.User = new ClaimsPrincipal(new ClaimsIdentity());
var logout = await _interaction.GetLogoutContextAsync(model.LogoutId);
return Redirect(logout?.PostLogoutRedirectUri);
Thanks,
You cannot revoke JWTs: once issued they are valid until they expire. So if you are using Identity Server to issue JWT access tokens then you what you ask isn't possible, so long as something has the JWT (and it hasn't expired) then it can be used to gain access to your resources.
Instead you could change to using Reference Tokens, which aren't self-contained and upon each use will cause the receiving resource (such as your API) to verify it with the IdSvr. One of the effects of this is that you can then revoke your access tokens, which means it doesn't matter if other tabs think they have the access token because when they try and use it the IdSvr will know that they are no longer valid. If you go down this route you will now need to persist your access tokens, and each protected call to your client will involve it doing a back-channel communication to your IdSvr.
We are trying to build OAuth2 Authorization with IdentityServer3.
So we downloaded the Bytes from nuget and connected it with our database.
The database was initialized with the default scopes and the sample clients from Thinktecture self.
Then we connected AD FS as IDP via OWIN and made an simple ExternalUserService.
So far everything worked fine and the permissions page of the IdSrv could be opened, showing the username and that no application has consent up to now.
Then we tried to connect Xamarin.Auth to that and got an error Cannot determine application to sign in to and in the logs an error Signin Id not present (after logon at the ADFS IDP).
To reduce complexity, we decided to go back to the InMemoryUserService and created one InMemoryUser. This worked for the permissions page (at least for a short period of time - time is over now), but it did not allow OAuth2 Authorization Code Flow, which ended up in showing the login page again and again and again. And there is no evidence of any error in the logs.
How can we debug, what is happening? Is there any way to see, why a user gets redirected to the login page again despite being logged in?
--
We reduced the complexity even further by creating a new empty MVC application, which just uses a simple InMemoryUserFactory.
Now it's getting a little bit confusing: one user was able to logon from his machine - other machines (same user - since we created only one) are not able to login and get prompted with the login over and over again.
If using IdentityServer3 and you use own external login methods you should really pay close attention to the API of the IdSrv3.
We tried to create a login resutl with just the subject - this is made for local login on the server. If this is switched off at the same time, you will end up having problems.
So if you use an own external login provider and switch off local login, make sure to call the right overload for the authenticate method (3 Parameters in our case).
Hello i am new in sharepoint development. I am working on an application in which we are using FBA. For logout purpose we are using a custom logout page and on that page we are clearing everything session, cookies. Now when a user is loggedIn one can use this tool http://portswigger.net/burp/ to copy and save cookies and entire session data of loggedIn user. Now after logout this can be easily use to loggedin a user again. Nothing worked for me, though i have expired auth cookies while logout. any suggestion how to make a user not able to loggedIn with cookies saved through the burp tool..
You can issue an encrypted cookie that would store the session ID. Add a control to the header of the site that would compare the encrypted header to the current header. If they don't match, sent the FedAuth cookie to expire now.