How exatly works JWT token security management using REST API?

Question

I am studying RESTfull API management and I am finding some difficult to understand how exactly the security is handled by the API KEY concept.

So from what I have understand studying on some tutorial I have the following situation:

The user that want to use my API have to register and, after the registration, he obtain his personal API KEY (that is something like to a long random string).

So this secret is stored in the database with its secret, so after the user registration I will have something like this into a database table (correct me if I am doing wrong assertion because I am absolutly not sure about it):

+--------------------------------------------------------+
|    USER             API_KEY          API_SECRET        |
+--------------------------------------------------------+
| user1    dfdsf3dsfsdg35gsgg4fdgd      SECRET1          |
| user2    vbgggh3bfdgdf2gfdgd5vbb      SECRET2          |
| user3    gfgdfgd57bfgdfg9dgfd2vg      SECRET3          |
+--------------------------------------------------------+

• Where the USER column contains the registerd user.
• The API_KEY contains the obtained api key that have to be inserted into the application devloped by this user.
• The API_SECRET what exactly is? From what I have understand is something that is automatically generated when the API KEY is generated, or is something like a password specified by the user during the registration prcess? This point is pretty obscure for me. What exactly is it?

Now let consider how a client perform an autorization on the API server.

It send a JWT (JSON WEB TOKEN), that could be something like: XXXXX.YYYYY.ZZZZZ

It is divided in 3 differend section:

1) YYYYY: HEADER. BASE64 ENCODED. CONTIENE METADATA.

Something like:

{
    type : "JWT",
    alg : "HMAC"
}

It will be encoded in base64 and so it is generated the XXXXX section.

2) YYYYY: PAYLOAD: that contains the claims, something like this:

{
    exp : 2828288,              // REGISTERED
    iss: "myApiProvided.com",   // REGISTERED
    name: "Andrea"              // PUBLIC
}

It will be encoded in base64 and so it is generated the YYYYY section.

3) ZZZZZ: SIGNATURE It is created in the following way:

• Create a string by the concatenation of: the previous: XXXXX + "." + YYYYY (both are base64 encoded).

• Then is generating the hashing of the previous signature using the SECRET. So from what I have understand basically in this way I have an encrypted version of the signature. Is it correct?

And here I have my secondo doubt: from what I have understand this hashing have to be generate by the client that send the token attacched to the request. So is this hashing made at client side? If yes it means that the client know the SECRET but it seems me strange.

How exactly works?

Answer 1

The digital signature of the JWT is perfomed with the private key of the sender (the SECRET). Validation of this signature ensures identity of the signer and that the message has not been altered.

Posession of a valid JWT is the proof-of-authentication in the API. To generate a valid token the client must be in possesion of the SECRET.

You can use a symmetric key, where the secret is shared, or a asymmetric key. During the registration, the client generates a key pair, private and public. The public key is sent to server and is associated with the client's account. JWT is signed with the private key. The server verify the signature with the public key.

In the case you describe, the secret will be a passphrase required to user or a random string. Client & server will derive a symmetric key from secret, i. e. HMAC, and use it to sign and verify the token

To use a assymetric key you would need to require to user during registration the public key previously generated. This scenario is a bit more complex, but avoids sending keys about the network, and the server does not need to know the secret