I would like to switch the security layer of my API from Basic Auth over HTTPS + claims-based infrastructure (w/ claims populated in a delegatinghandler) to a more robust mechanism and support client app authentication. I have a few questions about that.
Scenario: I have/will have: - X client applications consuming an existing REST API (both internal web/native apps & partners) - Y users
JWT crossed my path but I am confused about the way to authenticate a user Y (user that would try to log in from X).
Should I let the client apps create a JWT then pass the user's name and password in the JWT's body? It is sensitive data so I should probably require the JWT to be encrypted, right? Then, if both the client app X and the user Y are known, the authServer would append some more claims to the JWT's body (roles etc.), sign it again, base64 it, store it into the db along with the expiration date, then return it to the client application X so that they can consume the private endpoints... What do you think? It is quite a lot of work from the client...
Another option would be to 1/ require OAuth2 for user authentication and 2/ JWT for client authentication + ability to store user's claims in the token.
What do you think? Do you see another option?
Relevant conversation -> JSON Web Tokens (JWT) as user identification and authentication tokens
Thanks for your help, Toni
