In ASP.NET forms Authentication how authentication ticket inside authentication cookie is being validated?

Question

When Forms Authentication is enabled, once the user provides a username and password it will be validated using web config or using a database(if custom implemented) and will create an Authentication Cookie which will have an authentication ticket.

Now FormsAuthenticationModule will be responsible to check if this Authentication ticket is valid on every request.

The authentication ticket is generated using

FormsAuthentication.RedirectFromLoginPage("userName", isPersistentCookie)

Q1. Is this authentication ticket is stored in the server too or only in the cookie?

If only in Cookie and not in server:

Q2. If this authentication ticket information is not on the server how will FormsAuthenticationModule check if the cookie coming from the client is valid or not?

Q3. How will it know if the cookie is expired? It should have like when is the creation time of the cookie to tell if it is expired right?

Q4. If in case I am using database and now Admin user has deleted the non-admin logged-in user from DB. Now the next request from the non-admin user to the server, the cookie should be invalid, right? Is this even achievable using forms authentication?

Q5. Just my assumption is that this authentication ticket is encrypted using some key and can be decrypted only by the server as it is the one that has the key? But here also I see an issue. For example, I take one application's cookie and then pass it to another application on IIS. Now how will FormsAuthenticationModule determine if this cookie belongs to this particular application?

Answer 1

At the end of the day, you really can't change how this works - so, the answers here actually don't help you much - but lets take them one a at a time anyway:

Q1. Is this authentication ticket is stored in the server too or only in the cookie?

the information is stored in the browser side.

Q2. If this authentication ticket information is not on the server how will FormsAuthenticationModule check if the cookie coming from the client is valid or not?

When you do ANY post back, that cookie is sent - and EVERY post back you run or do will cause a number of sql provider routines to run - including "GetUser()"

So, EVERY post back will use and run the the GetUser routine.

Q3. How will it know if the cookie is expired? It should have like when is the creation time of the cookie to tell if it is expired right?

Like any other cookie - some can sit around in the browser for MORE then a year - don't really matter. If the cookie was expired, the user would simply have to login again.

In fact, you often see this setting if you using the standard login control:

So, clicking remember me will save the cookie. If you don't, then in most cases you have to re-login the next time you come to the site. However, browsers often can and will remember this information for you - out side of YOUR control - based on users browser settings which you don't have control over.

has deleted the non-admin logged-in user from DB. Now the next request from the non-admin user to the server, the cookie should be invalid, right? Is this even achievable using forms authentication?

It not even a question of achievable - if you delete the user, then the sql authentication providers code runs - (in this case FBA, it will try to run GetUser). Get user is this code stub:

So, if you delete the user, then next post back, "GetUser" will fail, and they will be re-directed back to your logon page.

I take one application's cookie and then pass it to another application on IIS. Now how will FormsAuthenticationModule determine if this cookie belongs to this particular application?

I don't believe you can do the above. Each site gets it own logon cookie - you can't just take it and pass it off as another site url - that don't work to my knowledge. And the user will require a valid logon, and as noted, the GetUser gets called every time - the web browser will have to passed the logon information - and if it don't match, then again, you get directed to the logon page.