Authentication in ASP.NET Core Web API... Your Tips?

koeks525

Executive Member
Joined
Jul 14, 2012
Messages
5,315
Hi guys,

I would love to close off my ASP.NET Core Web API (only the mobile app should be able to get data from the API). I have seen a few video's and an article, and they seem to be pointing to using IdentityServer 4, for token based Authentication. I am using Microsoft SQL Server 2016 for my data storage.

What would you guys use? What other links should I also have a look at?
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
15,194
Hi guys,

I would love to close off my ASP.NET Core Web API (only the mobile app should be able to get data from the API). I have seen a few video's and an article, and they seem to be pointing to using IdentityServer 4, for token based Authentication. I am using Microsoft SQL Server 2016 for my data storage.

What would you guys use? What other links should I also have a look at?

Stay away, I used it on a project and regretted it greatly afterwards. If you want to have token based authentication and you don't need stuff like federation you can roll our own. I recently did that.

While generally rolling your own authentication is difficult, you're essentially just rolling the authentication backing store. The token can be jwt with payload encryption. standard JWT's do not have their payload encrypted but are tamper proof if using key/pair cryptography.

I would venture to say that depending on your requirements you want the API to be stateless in terms of security. You could populate the IPrinciple if you want. But generally I ensure that the client passes me a token, I validate it, get a bunch of scopes from it and verify that particular caller has the access to that particular end point. If they do not you just reject.

But if you want stuff like WS-Federation/Active directory etc, then ID4 does help in that regard.
 

Spacerat

Expert Member
Joined
Jul 29, 2015
Messages
1,328
Interesting topic...

Similar situation that I faced recently. My user store sits inside my own DB so I couldn't use the ASP.NET/ ID4. So I needed to dig a little to find alternatives. The challenge was that I still wanted to use the ASP.NET pipeline authorisation. To achieve this I needed to plug into the pipeline to perform authorisation and also hook ASP.NET into the existing authentication in my backend.

I opted for the following:
The client logs into the backend by sending a GET to my account controller with encrypted user/pass in the Authorization header. This user/pass is decrypted by the AccountController and authenticated against the backend API. If successful, the client gets issued a token in the response header.

Subsequent calls from the client to the controllers has to include the token in the header. I added a DelegatingHandler to the ASP.NET HTTP Pipeline to perform authorisation of the token against a token store before the request hits the intended controller. As semaphore stated, the above mechanism has the problem that in a federation setup, the token mechanism does not work. I am sure that my implementation has other flaws too...

I tried the same with ASP.NET Core, but I abandoned that quickly because of 2 reasons:
- As much as I followed instructions, I could not reference my own assemblies. Even though they were built with exact same framework version
- The ASP.NET Core pipeline seems a bit differerent and I could not get the Authorisation plugin to work.
 

Spacerat

Expert Member
Joined
Jul 29, 2015
Messages
1,328
Another option is Stormpath.

Looks interesting, but it seems that all of these ID servers mean that the user profile is offsite. How do you bridge the gap between the user profile in , say stormpath, and the rest of you application? In my case all the users' permissions , job functions etc sits within my own app.
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
15,194
Looks interesting, but it seems that all of these ID servers mean that the user profile is offsite. How do you bridge the gap between the user profile in , say stormpath, and the rest of you application? In my case all the users' permissions , job functions etc sits within my own app.

Go read their documentation they explain it.
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
15,194
I opted for the following:
The client logs into the backend by sending a GET to my account controller with encrypted user/pass in the Authorization header. This user/pass is decrypted by the AccountController and authenticated against the backend API. If successful, the client gets issued a token in the response header.

A GET? You mean a POST? GETS are cached, POSTS are not, so you could be leaking credentials.
 
Top