Good.
I want to know if you can help me with a concern that I am having in the development of an API with WEB API 2.
We decided with my team to implement token based authentication.
Once the user registers and then the token is generated, where is that information (token, from, to etc) persisted?
I don't see anything being saved to the Identity model (AspNetxx) tables.
Thank you very much for the help.
The token is generated based on the claims, when you expose the endpoint using the code
Important is the first line where you define the
/Token
from this is that the client consumes the service that will return the token that it requires to be authorized in the calls to the other requests. That's why it doesn't persist but is something temporary that you will use to invoke webapi services that require authentication.Secure a Web API with Individual Accounts and Local Login in ASP.NET Web API 2.2
On the one hand, there is the user registration, and on the other, how you ask for a token to be able to make the requests to the webapi services marked withn
[Authorize]
. From the article he analyzes the title "Configuring the Authorization Server" there he explains how to expose the service/Token
as an endpoint to be consumed by the client that requires an authentication token.When you need to invoke a webapi service, you must send that token in the header, which you will surely keep in the
storage
delhtml
.[ASPNET Web API] Working with bearer token in Web API
In this second example you will see how the token is sent as
Bearer
in the header.That is why on the one hand you have the user data to validate access and on the other the authorization system using tokens.
>>1) If the token is not persisted and is generated dynamically... Every time a request is made and the token is passed by heder (authorization) what does it compare against?
I understand that this is where claims come into play as the info you assign will be used to generate the token. If you analyze the example of the first link you will see a line that defines
You could analyze the code that implements it
github
ApplicationOAuthProvider.cs
You can locate the validation of user credentials
And how does it generate those
Claims
that will define thetoken
.On the side of the webapi service, when the token arrives, it will validate its validity, but not the user's credentials, that was already done when the token was requested. There is no communication between the client that receives the token and the server that generates it.
>>2) What happens if an iis reset is performed?
The token has the expiration time, it is more when it is defined
OAuthAuthorizationServerOptions
, this value can be specifiedAlthough the idea is to make it as small as possible, that is why it is recommended that you consider implementing the
RefreshToken
AngularJS: Enable OWIN Refresh Tokens Using ASP.NET Web API 2
As @rsciriano comments if you restart the client's IIS service the token will still be valid.
It
Token
is not stored on the server, but is sent encrypted to the client and contains all the information necessary to identify it and to check its validity.When, from the client, a request is made by sending the
Token
, the server decrypts it, checks its validity and establishes the security context with the data included in it.You can test this behavior using the "Secure a Web API with Individual Accounts and Local Login" project linked by @Leandro-Tuttini in his answer (it helped me to finish understanding all this) .
The first thing would be to do a test without modifying anything, we capture the authentication traffic and we copy the
Token
one that has been returnedWe then modify the method
GenerateUserIdentityAsync
by adding an additional Claim with aloremImsum
When testing again, we see how the size of
Token
has grown because it is including the newClaim
, that is, it includesToken
allClaims
of the user's identityThis article " Simple explanation of bearer authentication for Web Api 2 " (in English) is very interesting because it explains step by step how authentication works
Bearer
and one of the things they mention is that it isToken
not saved on the server but is sent encrypted.I have also verified that once authenticated, if you stop the site and restart it, you can continue making requests using the
Token
one you have saved (it is able to decrypt it and is still valid). For this reason, one of the recommendations made in the article is that the validity of the certificateToken
be very short.Another thing to keep in mind is the DataProtectorTokenProvider that is used to encrypt the Tokens because the one used by default is based on local server keys, so it would not work in a load-balancing environment (in these environments you could use one based on certificates)