CODEWITHSUNDEEP
c#.netauthenticationasp.net-web-api
Francis Ducharme
Francis Ducharme

Reputation: 4987

Web API 2 custom authentication

I'm trying to come up with an authentication approach that is custom. That is, user information is in the table and I'm doing the username and password verification myself, in the API.

For this solution, I'm trying not to use ASP.NET Identity.

On a previous project, I did something like this where I would verify the password provided, when successful, return a session GUID in the response cookies which would then make the client send this session GUID with all subsequent requests to the API.

Through an action filter, I would then use the GUID (and the IP of the client making the request) to look up in a table to see if the session is still active and matching the IP that created the session in the first place.

What I would like this time is avoid having to look up in the database at each request I'm getting on the API.

Is there any way to register the GUID tokens and other information, in memory on the server ?

What kind of authentication should I look into ?

Upvotes: 2

Views: 1693

Answers (4)

Chris Charabaruk
Chris Charabaruk

Reputation: 4417

Don't. As Win said, keeping all these tokens in-process will cause problems if the process for the site terminates (spun down, crashes, etc.)

If you want to avoid storing the token data in your primary SQL database, you should probably look into Redis or similar programs. Alternatively you can use something like SQLite for a lightweight in-process database backed by a file but you'd have to keep timestamps to expire tokens manually (with Redis you can tell it to expire automatically after so much time).

I implemented auth token caching with Redis for a project, and it's not very difficult to work with, especially when using the NuGet package that Stack Exchange provides. I just mapped tokens to user IDs but you could keep the whole user record if you wanted.

Upvotes: 1

Win
Win

Reputation: 62260

Is there any way to register the GUID tokens and other information, in memory on the server ?

That is not a good design. Mainly, if application pool recycles or application crashes, all users have to re-login again.

You might want to consider using ASP.Net Web API's built in Token-based Authentication.

How

When you create ASP.Net Web API project with Individual User Account, it automatically generated it for you.

Startup.Auth.cs file contains code to configure OAuth2 Authorization Server.

If you do not like using ASP.Net Identity, you can modify ApplicationOAuthProvider with your own code.

Upvotes: 1

Prescott
Prescott

Reputation: 7412

As some of the comment allude to, I'm not sure I see a reason for you to avoid the built in Identity Service / Providers. They are pretty solid and will support what you want do do. You can of course implement your own solution if you really wanted to, but based on what you've told us here, I'm unconvinced that's the best approach.

You can then override the login mechanism. After a user authenticates with username and password, generate their token, their IP address (and whatever other identifying information you need) into whatever you use for a session store. One comment suggested looking at Redis - that is a pretty good key/value store for speed, and avoids a stickyness problem that an in memory solution (application global object) would have.

Create the token cookie on your login response.

Then override the AuthorizationFilterAttribute to take the token from the cookie to look it up in your session cache, and if required validate IP address is the same.

Upvotes: 0

gilmishal
gilmishal

Reputation: 1982

You should look into Json Web Tokens, it's a json object that contains claims about a certain user - that object is hashed and the server knows who is the user and takes away the need for looking up at the database, and it doesn't require you to cache each Guid.

Upvotes: 1

Related Questions