In my Web Api 2 Identity 2 application after user registration I have a single record in single table: AspNetUsers. I use the following http request to get token:
POST https://localhost:44304/Token HTTP/1.1
Accept: application/json
Content-type: application/x-www-form-urlencoded
Accept-Encoding: gzip
Content-Length: 68
Host: localhost:44304
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
grant_type=password&[email protected]&password=123456
and I get the response with access_token:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 695
Content-Type: application/json;charset=UTF-8
Expires: -1
Server: Microsoft-IIS/8.0
X-SourceFiles: =?UTF-8?B?QzpcVXNlcnNcU2VyZ2V5XERvY3VtZW50c1xWaXN1YWwgU3R1ZGlvIDIwMTNcUHJvamVjdHNcbXZjX3dlYmFwaVxXZWJBcHBsaWNhdGlvblxXZWJBcHBsaWNhdGlvblxUb2tlbg==?=
X-Powered-By: ASP.NET
Date: Tue, 25 Nov 2014 17:40:07 GMT
{"access_token":"gsvW23e1...}
After I have got the token no one record is added to the database. Still there is just single record in the table AspNetUsers. No information about the issued token is stored in any table in the database.
I use the following code in web api controller to authenticate user:
var currentUser = manager.FindById(User.Identity.GetUserId());
if (currentUser == null)
{
HttpResponseMessage response = new HttpResponseMessage(HttpStatusCode.Unauthorized);
return ResponseMessage(response);
}
After that I perform password change and trying to call some web api controller method using the old access_token (which I got before password change) and the access_token is still valid! The currentUser is not null! I have read another threads on stackoverflow ASP.Net Identity sign-out all sessions ASP.Net Identity Logout and blogpost https://timmlotter.com/blog/asp-net-identity-invalidate-all-sessions-on-securitystamp-update/ but I still don't understand where the information about the issued tokens is stored. So my questions are: 1) Where is the information about the access_token stored on the server? 2) Why after password change I can still use the access_token which is issued by the server before the password change? 3) How to invalidate all the access_token issued before password change?
By default the token is not stored by the server. Only your client has it and is sending it through the authorization header to the server. If you used the default template provided by Visual Studio, in the Startup ConfigureAuth method the following IAppBuilder extension is called: app.
The client, in OAuth terminology, is the component that makes requests to the resource server, in your case, the client is the server of a web application (NOT the browser). Therefore, the access token should be stored on the web application server only.
Using the [Authorize] Attribute Web API provides a built-in authorization filter, AuthorizeAttribute. This filter checks whether the user is authenticated. If not, it returns HTTP status code 401 (Unauthorized), without invoking the action.
To get this token, you call the Microsoft Authentication Library (MSAL) AcquireTokenSilent method (or the equivalent in Microsoft. Identity. Web). Call the protected API, passing the access token to it as a parameter.
1) Tokens are not stored anywhere in the database or local storage. That means tokens are not storing anywhere in the server.
2) Actually, password reset tokens are generated using the SecurityStamp and validating against the SecurityStamp of the user. Tokens are not expire unless you haven't set up expire time or updated SecurityStamp of that user.
Expire time can be set on userManager properties on your identity configuration class. Following example shows token lifetime with 1 hour. Check this article.
if (dataProtectionProvider != null)
{
manager.UserTokenProvider =
new DataProtectorTokenProvider<ApplicationUser>
(dataProtectionProvider.Create("ASP.NET Identity"))
{
TokenLifespan = TimeSpan.FromHours(1)
};
}
You can use your own mechanism to check token's have previously used.
3) Update the SecurityStamp. This will invalidate all tokens issued for that user, including cookies as well. It would be better to use your own idea to make expire password reset tokens.
As a example you could use another column to store any generated password reset tokens in database and validate it (There may be better way to do it).
Keep in mind that the login access_token generated differently and it has expire time which you have set in Owin startup bearer token expire time.
Hope this helps.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With