Is it right to create a viewmodel for registration (post) and another for consultation (get) of a User entity?

Question

I am taking my first steps in Web API. I created a Viewmodel of the User entity, I will use it for user registration. Now, when returning the data, it has fields, like the password, which I don’t want to return in the JSON of the Web API. I should create another Viewmodel for this purpose, or there is another solution?

Answer 1

If you are in search of security for your Web.Api, hiding only the password is not the only thing you should do. And if you take into account the concept of DRY having two exactly equal entities with the difference that one object has one more field than the other is no longer a good idea.

However, there is a framework called JWT (Json Web Tokens)

JWT is an open standard (RFC 7519) that defines a compact, self-contained mode for securely transmitting information between parts as a JSON object. This information can be verified and trusted because it is digitally signed. Jwts can be signed using a key (with the HMAC algorithm) or a public/private key pair using RSA.

Let me explain a few more concepts of this definition:

Compact: Due to its smaller size, Jwts can be sent via a URL, POST parameter, or within an HTTP header. Also, the smaller size means the transmission is much faster.

Self-contained: The cargo contains all necessary information about the user, avoiding the need to query the database more than once.

When to use JSON Web Tokens?

Here are some scenarios where JSON Web Tokens makes itself very useful:

Authentication: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services and features that are allowed with this token. Single Sign On is a feature that uses widely JWT nowadays due to its small overhead and its ability to be easily used in different domains.

Information Exchange: JSON Web Tokens is a good way to securely transmit information between parties, because as it can be signed, for example, using public/private key pairs, you can be sure that senders are who they say they are. Also, since the subscription is calculated using the header and payload, you can also check that the content has not been tampered with.

What is the JSON Web Token structure?

JSON Web Tokens consist of three parts separated by dots (.), which are:

Header Payload Signature

Therefore, a JWT usually looks like the following.

xxxxx.yyyyy.zzzzz

Let’s better understand each of these blocks:

Header

The header typically consists of two parts: the token type, which is JWT, and the hashing algorithm being used, such as HMAC SHA256 or RSA.

For example:

So this JSON is Base64url encoded to form the first part of JWT.

Payload

The second part of the token is payload, which contains the Claims. Claims are statements about an entity (usually the user) and additional metadata. There are three types of Claims: private, public and reserved Claims.

Reserved claims: this is a set of predefined Claims that are not mandatory but recommended, to provide a set of useful and interoperable Claims. Some of them are: Iss (emitter), Exp (expiration time), sub (subject), Aud (public) and others.

Note that Claims names are only three characters long as JWT is intended to be compact. Public claims: These can be set at will by those who use Jwts. But to avoid collisions they must be defined in the IANA record of the JSON Web Token or be defined as a URI that contains a collision-resistant namespace.

Private claims: these are custom claims created to share information between parties who agree to use them.

An example of payload can be:

Signature (Signing)

To create the signature part you have to take the encoded header, the coded payload, a secret, the algorithm specified in the header, and sign it.

For example, if you want to use the SHA256 HMAC algorithm, the signature will be created as follows:

The signature is used to verify that the JWT sender is who he says he is and to ensure that the message has not been altered along the way.

Putting it all together

The output is three point-separated Base64 sequences that can be easily passed across HTML and HTTP environments, being more compact when compared to XML-based standards such as SAML.

The following picture shows a JWT that has the previous header and payload encoded, and is signed with a secret.

If you want to play with JWT and put these concepts into practice, you can use the Debugger of jwt.io to decode, verify and generate Jwts.

How JSON Web Tokens work?

In authentication, when the user logs in with their credentials successfully, a JSON Web Token will be returned and must be saved locally (usually in local storage, but cookies can also be used)instead of the traditional approach of creating a session on the Server and returning a cookie.

Whenever the user wishes to access a protected route or resource, the user’s agent must send the JWT, usually in the Authorization header using the Bearer schema. Header content should be similar to the following:

This is a stateless authentication mechanism, since the user’s state is never stored in the server’s memory. Protected server routes will check for a valid JWT in the Authorization header and, if present, the user will be able to access protected resources. As Jwts are self-sufficient, all the necessary information is there, reducing the need to query the database several times.

This allows you to rely entirely on data Apis that are stateless and even make requests for downstream services. It doesn’t matter which domains are serving your Apis, so Cross Source Resource Sharing (CORS) will not be a problem as it doesn’t use cookies.

The following diagram shows this process:

Why we should use JSON Web Tokens?

Let’s talk about the benefits of JSON Web Tokens (JWT) when compared to Simple Web Tokens (SWT) and Assertion Security Markup Language Tokens (SAML).

Since JSON is less detailed than XML, when it is encoded, its size is also smaller, making JWT more compact than SAML. This makes JWT a good choice to be passed in HTML and HTTP environments.

In terms of security, the SWT can only be symmetrically signed by a shared secret using the HMAC algorithm. However, JWT and SAML tokens can use a public/private key pair in the form of an X.509 certificate for signature. Signing XML with XML Digital Signature without introducing obscure security holes is very difficult when compared to JSON’s signature simplicity.

JSON parsers are common in most programming languages because they map directly to objects. On the other hand, XML does not have a document to natural object mapping. This makes it easier to work with JWT than SAML assertions.

As for use, JWT is used on the Internet scale. This highlights the ease of processing the JSON Web token in the client across multiple platforms, especially mobile.

This is the comparison of the length of an encoded JWT and an encoded SAML.

If you want to read more about JSON Web Tokens and even start using them to perform authentication on your own applications, go to the JWT page and learn everything you need to.