0

I'm looking to add a database check to my JWT Token validation in an ASP.NET Core 2.2 Wep Api application.

In simple terms, after the JWT has been validated by netcore I want to then check that the corresponding "user" entity exists - if not then this should be a failed Authentication.

I've found a post that discusses additional validation, using an override of JwtSecurityTokenHandler but there are DI issues.

The alternative seems to be creating an Authorisation policy using AuthorizationHandler<T> overrides - but again, there are DI issues.

My question boils down to 2 parts:

  1. Is Authentication the right place for this check or is it Authorisation (it feels like the former, but you could argue JWT validation has already "authenticated" the caller)?
  2. If I use JwtSecurityTokenHandler or AuthorizationHandler<T> to do my database check - using EF Core - do I have any alternative to using Service Locator (by passing a reference to the ServiceProvider into the instances created during startup in order to get a Scoped DbContext when required)
oatsoda
  • 2,088
  • 2
  • 26
  • 49
  • It feels like this should be done on authentication and not authorization, authorization is is primarily for restricting certain sections of the application to different users with roles. Doing this check on every JWT validation sounds simply expensive. You might elevate the pressure this by caching the amount of users (ids) server side but this would affect new users – cl0ud Apr 26 '19 at 09:39
  • @cl0ud Yeah, I agree, but was seeking some clarification. I guess I really should trust a JWT which has a valid signature.... I'm not using this on a User basis - otherwise I would probably use ASP.NET Core Identity (I suspect they *don't* validate against the DB). – oatsoda Apr 26 '19 at 09:52
  • Can you clarify why you wish to verify a users existence in a database? Is there an option where someone is not registered and can get a token? Id imagine a successful login already gives you enough indication of existence. – cl0ud Apr 26 '19 at 12:45
  • @cl0ud It's case where I am generating and issuing the tokens myself. It's an odd use-case. The tokens do not expire so I thought I should probably ensure that, as well as being valid signed tokens, they are for a valid target too. But I am starting to lean towards not bothering... – oatsoda Apr 26 '19 at 13:18
  • Are you speaking about the process of impersonation basically? – cl0ud Apr 26 '19 at 13:25
  • @cl0ud Not really - I am providing a token for access. It's just that I am creating it rather than the user requesting it. And I am making it infinite. Did you have some ideas around impersonation then? – oatsoda Apr 26 '19 at 14:01
  • When you are generating the token, can you not perform a check at that time if the user exists? If it is, then add a claim to the JWT token that indicates that user does exist. Then using a CustomAuthorization policy add a `Requirement` that checks for that claim – Shahzad Hassan Apr 26 '19 at 19:38
  • @ShahzadHassan Yes, of course. The issue regarding checking the DB during Authentication is whether it *still* exists. But having considered it, I now don't think it is really worth it doing the check. – oatsoda Apr 29 '19 at 07:15

0 Answers0