0

I'm developing an angular app with REST api on ASP.net Core basis. Now, I reached the point, where the login feature has to be implemented using Identity.

Currently, I'm aware of the following methods to do this:

  1. login view in ASP.net Core, after login redirect to index view, which hosts the angular entry point
  2. login view in angular, use of api calls for log in and log out
  3. use of a separate IdentityServer for authentication, one server for the resources (the data) and the angular app (this is for my tiny app an overkill)

So, my questions are:

  1. Should I go for option 1 or option 2?
  2. What are the pros/cons of this options?
  3. Is there some best practice?

Thank you.

derstauner
  • 1,478
  • 2
  • 23
  • 44
  • This depends on the kind of app your are developing and how many visitors/users you are expecting. Both 1 and 2 seems to be good options, where 2 might be better scalable. – n9iels Jul 18 '20 at 11:15

1 Answers1

0

There are two different ways of implementing Angular side authentication via JWT.

Stateful JWT

The session is stored on the server, and Reference Id is returned to attach with every client request to the Server.

Following is the list of pros & cons of the Stateful JWT

Pros

  • A single token to pass back and forth to fetch/store etc
  • The session can be revoked at any time
  • Impossible to steal user information from the token as it only possesses Reference Id to the session

Cons

  • The server occupies more resources as the number of users increases
  • If the sessions are distributed in different servers, we need to implement a tracking algorithm to link a specific user session and the specific session server.
  • While adding new instances, there is a need to implement additional scale to session storage as well

Stateless JWT

All the user information is stored on the client-side and the server can only validate the request to match the payload against the signature.

Following is the list of pros & cons of the Stateless JWT

Pros

  • The token contains all the related information so no further request will be made to fetch its information
  • Removing the session dependency from the Server-Side
  • Reduce the number of database access

Cons

  • Individual tokens can not be invalidated because they are by design valid until they expire
  • All parts of the application have access to all the data
  • Session identifier contains all authentication information and it is possible to steal sensitive information, it is not encrypted.

Authentication via Back-end

The user credentials are verified on the server. Upon successful authentication, a cookie with the session ID is placed in the user's browser.

Following is the pros & cons

Pros

  • Full control of session - Can terminate a session on demand instantly.
  • Implementation of session management can change easily since we store the session state ourselves and is not “in the wild” (i.e. not stored on many different browsers).
  • Implementation and user details are not exposed since only reference to session data is stored in the cookie.

Cons

  • More points of failure - If the DB is unavailable, no sessions can be created touched or validated
  • More overhead in creating and touching session (a DB read, write and replication is required). This can be mitigated by applying the DB write asynchronously.
  • No future potential for applications to verify session without having to call nodes.

Helpful resources

Basheer Kharoti
  • 4,202
  • 5
  • 24
  • 50