CODEWITHSUNDEEP
javascriptc#asp.net-coreknockout.jsjwt
Barrett
Barrett

Reputation: 151

JWT-based authentication in ASP.NET Core SPA - front-end validation

I'm currently playing around with a KnockoutJS SPA template in ASP.NET Core 2.1, and I managed to implement an authorization flow exactly as this one which was made in Angular:

https://fullstackmark.com/post/13/jwt-authentication-with-aspnet-core-2-web-api-angular-5-net-core-identity-and-facebook-login

As you can see in their User front-end service, basically the only check for whether the user is logged in on the client side is the check if the "auth_token" key exists in the client's local storage:

https://github.com/mmacneil/AngularASPNETCore2WebApiAuth/blob/master/src/src/app/shared/services/user.service.ts

this.loggedIn = !!localStorage.getItem('auth_token');
// ?? not sure if this the best way to broadcast the status but seems to resolve issue on page refresh where auth status is lost in
// header component resulting in authed user nav links disappearing despite the fact user is still logged in

Simply put, anyone can open up the browser local storage and insert a random string with the "auth_token" key and they'll be able to see everything admin-related in the UI (even though they will fail on API requests).

Can someone suggest a better flow for this? Or is the only option to send a "log in request" to the API, whenever an admin page is "opened"?

P.S. I am relatively new to the authentication schemes front, should JWT perhaps not be used for client-side content validation?

Upvotes: 0

Views: 1261

Answers (1)

Lucas Carneiro
Lucas Carneiro

Reputation: 570

Considering JWT best practices, all your validations should be done in your back-end, since any validation coded in your web app could be read by any of your clients, resulting in a huge security flaw: anyone would know how to create a valid JWT for your application.

Is it a big problem to be possible to see your admin-related UI, even without any data? Considering that all of the routes which can return sensitive data are protected by JWT authorization, if a user access any pages or parts of your UI which require data, they would trigger a request to retrieve it, which would probably return a 401 (Unauthorized) HTTP status, or similar. A common front-end practice in these situations is to erase client user data, and redirect to a login page.

So, a typical flow would be:

  • User inserts a fake access token into their storage
  • User opens an admin page/ui which uses sensitive data in any way (showing, using for any internal logic, etc)
  • Web app does a request to the API requesting data
  • API returns a response which will be interpreted as an authorization error
  • Web app receive the API response, erase user access token and redirect them to its login page

In most cases, this entire flow will happen fast enough to block your user to further interact and explore your web app.

Would be better if you provide more information about your scenario, so anyone could understand if your worries are something that needs to be considered and truly solved. However, in most cases, the behavior above is accepted.

Upvotes: 2

Related Questions