auth

Authentication and Authorisation for micro-services

Interaction model with JSON Web Tokens (JWT)

This is the procedure of authentication for micro-services that is often used in practice.

Step 1: C → A: C_id, K_c

In step 1, client or user C sends C_id and K_c to the authentication server A.

The C_id can be the username or user id of the user C.

K_c can be the password that the user inputted.

Step 2: A → C: T_CS

In step 2, the authentication server A verifies the information of the user id C_id and the key K_c in the system. If the information is correct, a ticket T_CS will be returned to the client C.

The client C will use the ticket T_CS in the requests to access resources on the server S in the next step.

When JSON Web Tokens - JWT is used to implement the ticket T_CS, the ticket T_CS is formulated as a triple of header, payload, and {header, payload}_K, where {header, payload}_K denotes that the information of header and payload is encrypted by a secret key K. {header, payload}_K can be seen as a signature signed by the authentication server A.

Step 3: C → S: T_CS, request

In step 3, the client C sends requests to the server S. The ticket T_CS is attached in each request to the server S. The server S can be a resource service or it can be a gateway server for accessing several resource services in the architecture of micro-services. The server S needs to verify T_CS to make sure that the request is authenticated before the server S performs the request from the client C. In the process, the server S may need to ask the authentication server A to verify the ticket or it may verify the ticket itself, before the server S performs the request from C.

When JSON Web Tokens - JWT is used, the ticket T_CS can be verified by using the knowledge of the secrete key K and the algorithm that we used to obtain {header, payload}_K.

Step 4: S → C: result

In step 4, the server S returns the result to the client C.

Problems with the authentication in the model

When JWT is used, the ticket is designed so that the server can verify it. There are problems with the solution.

Problem 1

I am the client, I have just sent you (the authentication server A) my username and password, and I have received a JWT ticket. How do I verify that the JWT ticket I have obtained is really from you?

Problem 2

I assume that the ticket can be verified that it is from you. Is the ticket for me only? Can other people steal and use it? Can someone just use a ticket which they know it can be verified and send it to me so that I would use the ticket to send my important data in my requests?

Problem 3

I have used my username and password to log-on on different apps. Can each ticket be used only in each session on each app?

Problem 4

I have just sent you, the server S, a request with a ticket from you, and I have received a result. How do I verify that the result is for the request data I have sent to S and it is not from someone else?

Problems with the authorisation in the model

As mentioned above, S in the interaction model is a resource server or can be a gateway to access several resource services. The ticket T_CS is used to access any resource server or resource services in the system. There is no design in the interaction model to say if the client can access a particular resource server or a resource service.

In practice, we may have several resource servers/services in the system. Each resource server/service manages several resources inside. Therefore, a verfication is necessary to check whether the client can access a resource service, before we conduct another check to see if the client can access a particular resource in the resource service.

A proposed solution for authentication only

In this section, I describe an interaction model to deal with the problems that I have mentioned above. I have not resolved the issues of authorisation in this proposal yet. The problem of authorisation in the model can be resolved easily and will be presented in the next section.

Step 1: C → A: C_id, K_c, n₁

In step 1, the client C sends C_id, K_c, and a nounce n₁ to the server A. The C_id can be the username or user id of the user C. K_c can be the password that the user inputted. The nounce n₁ can be a random string or a timestamp generated by the client C.

Step 2: A → C: {K_CS, n₁}_KC, T_CS={C_id, t₁, t₂, K_CS}_KS

In step 2, the server A verifies C_id and K_C in the system. If it is successful, the server A generates a random key K_CS for the communication between C and S. Then the server A encrypts the key K_CS and the nounce n₁ together by using the key K_C to obtain {K_CS, n₁}_KC to send to the client C. Since the client C knows the key K_C, the client C can decrypt and get the key K_CS and the nounce n₁ in the result. The nounce can be verified by comparing with the nounce that the client C generated and sent to A in the step 1.

Moreover, a ticket T_CS for the communication between C and S is also created and returned to the client C. In the ticket, the values t₁ and t₂ are to define the starting time and ending time for the validity of the ticket. The ticket T_CS is encrypted by using a secret key K_S, which is known by the server S. Therefore, the server S can decrypt the ticket T_CS to get the key K_CS inside the ticket in the next step. Asymmetric cryptography can be considered to encrypt and decrypt T_CS if necessary.

Step 3: C → S: {C_id, n₂}_KCS, T_CS, request

In step 3, the client C uses the key K_CS obtained from the server A in the step 2 to encrypt C_id and a nounce n₂ to have {C_id, n₂}_KCS. The client C attachs {C_id, n₂}_KCS and the ticket T_CS on each request to send to the server S. The request data can be encrypted by using the key K_CS if necessary.

Since the server S knows the key K_S, it can verify and decrypt the ticket T_CS to obtain the key K_CS. Then the server S uses the key K_CS to decrypt {C_id, n₂}_KCS in each request to verify C_id and get the nounce n₂ generated by the client C.

Step 4: S → C: {n₂}_KCS, result

In this step, the server S performs the request to have a result. The result can be encrypted by the key K_CS if neccessary. The server S uses the key K_CS to encrypt the nounce n₂ to return to the client in the result. The client C can verify the result from the server S by using the key K_CS to get the nounce n₂ and compare it with the nounce that the client C generated and sent to S in the step 3.

A proposed solution for authentication and authorisation

The interaction model proposed in the previous section has not resolved the issue of authorisation yet. In practice, the server S can be a resource service or can be a gateway to several resource services in the architecture of micro-services. We need to verify if the client C has rights to access a resource service before the client C can send requests to perform operations on a resource service in the step 3.

More details will be added later.