Should we be parsing JWT on the client side or the server side?

Help
1

In the lock-passwordless docs, it shows that we get a user’s info on the client side using JQuery. Is it recommended that we parse the hash and getProfileor getUserInfo on the client side? Wouldn’t it be safer to do on the server-side?

// parse hash on page load
$(document).ready(function(){
  var hash = lock.parseHash(window.location.hash);

  if (hash && hash.error) {
    alert('There was an error: ' + hash.error + '\n' + hash.error_description);
  } else if (hash && hash.id_token) {
    //use id_token for retrieving profile.
    localStorage.setItem('id_token', hash.id_token);
    //retrieve profile
    lock.getProfile(hash.id_token, function (err, profile) {
      if (err){
        //handle err
      } else {
        //use user profile
      }
    });
  }
});
2

Technically speaking it would be safe to say that anything happening/running client-side on an end-user device has a larger attack surface than something on the server-side. Having said that, the reality is that we have both client-side applications and server-side application and authentication is sometimes required in both so it needs to be available to both paradigms.

What you have to have in mind is that the process to perform that authentication will likely vary. For example, focusing on the OIDC/OAuth 2.0 protocols there is a clear distinction in the recommended flows to perform depending on the client application type. See:

In conclusion, if you have the choice between implementing something as a client-side application or a server-side application then you may gain some simplicity by going server-side and likely reduce the attack surface, but it’s still perfectly viable to have authentication in a SPA. In addition to that, the code snippet you shared seems to be using some legacy endpoint as currently ID tokens should not be used in a call to obtain user profile.

3

@jmangelo Thank you for the comprehensive answer. This could be a fault in my lack of experience, but when would you need to authorize only on the client side (i.e. no server-side API involved)? I can’t seem to think of scenarios when this would be practical. Would this be simply to reflect a UI change? Maybe a logged-in view vs a logged-out view?

4

No authorization; what I mentioned was authentication where ID tokens are generated and a SPA use the information within them to customize it’s UI to signal that a certain end-user is authenticated (ID tokens may contain user data like emails, usernames). It should only do that after validating the ID token which by spec is a JWT. Access tokens issued to client application can also be JWT’s, but in that case the client application treats them as opaque and does no validation or assumption about the format; it just sends it to the respective API and the API does the validation.