2

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 ?

Improve this question
3
  • 2
    I'd suggest you to let Identity handle all that, and modify it to provide custom username and password verification only. Other than that, you could take the trouble of creating classes to handle ConcurrentDictionary's and store your data there; not sure if this would be the best approach though. Commented Dec 31, 2015 at 17:55
  • 1
    In web case I would suggest using distributed cache like Redis. It is outer process so you don't have to implement stickiness to a certain server. And if your server is going down your Guid will stay. Commented Dec 31, 2015 at 18:07
  • 2
    Use filters in Web API. Create a class that inherits AuthorizationFilterAttribute. That will only intercept the call before getting to the method. How you authenticate is entirely up to you. Commented Dec 31, 2015 at 18:34

4 Answers 4

Reset to default
1

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

I think I've created the project without this option, so there is no such file. However, I can add an OWIN Startup Class item. Is that it ? If so, it's empty when added.
Well. There are few more files; you also need to override OAuthAuthorizationServerProvider. If you are new to OAuthAuthorizationServerProvider, you might want to start with auto generated code - ApplicationOAuthProvider.
Thanks Win. I ended up following your advice, using this tutorial: bitoftech.net/2014/06/01/…
1

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.

Improve this answer

Comments

1

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.

Improve this answer

Comments

0

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.