0

I'm trying to implement my own version of JWT Bearer authentication on top of ASP.NET 5, without referring to any existing JWT token handler classes. It's my exercise to understand internal mechanism of authentication and authorization.

I have a project to play around. See it here. JWT token code is in separate assembly - SimpleJwtAuth. It can generate the token by user login and password. But I have questions about Authentication. I inherited from AuthenticationHandler<TAuthOptions>, which can return AuthenticationResult.Failed or AuthenticationResult.Success with AuthenticationTicket.

The problem is that I don't see how this AuthenticationTicket could log the user in. Should I invoke SignInManager.SignInAsync by myself, or did I forget to set any parameters to make this happen automatically?

Speaking of examples: I see that it's the developer's code responsibility to sign the user in. It makes me think that i should do the similar thing. But then - why do we need AuthenticateResult and its tickets at all?

kosmakoff
  • 228
  • 2
  • 12

1 Answers1

0

Where do you see it's the developer's responsibility to sign-in?

SignInManager is part of the Identity package. If you're not using the identity package in conjunction with cookie authentication you don't need to call it. Returning AuthenticationResult.Success with a ticket is sufficient to put a Principal on the current request, which is effectively what logging in is.

blowdart
  • 52,422
  • 11
  • 102
  • 145
  • To consider user logged in, I need to fill in all of its claims and properties. Initially I thought that there must be some internal logic which expands the user object from minimal set of claims. Like if I returned the ticket with principal containing nameidentifier claim only, and it would automatically fetch the whole object by id. Obviously, it's not the case. Using UserManager to fetch the user object by id and return it with ticket works as needed. Just wanted to clarify if it's the correct way. – kosmakoff Feb 02 '16 at 09:17
  • Oh I see, you're hooking into identity. Then yes, by all means call into SignInManager.SignIn. That updates the last signed in field as well, but it's only needed if you're using identity as your user store, it's not needed for middleware if you don't. – blowdart Feb 02 '16 at 12:58