top of page

Secure Interface with a Microservice Augmenting a Token Claim


Below is a description and accompanying explanation of a state diagram representing a secure interaction between a client, an authentication service, and a microservice. The process involves securely augmenting a claim in an existing token.


State Diagram Description


Actors:

1. Client: The user or system initiating the interaction.

2. Authentication Service: The service issuing or validating tokens.

3. Microservice: A system entity that performs the business logic, requiring updated token claims.


States:

1. Idle: The initial state of the client or microservice, where no communication has occurred yet.

2. Establish Secure Connection: A secure connection is established via TLS/HTTPS between the client and microservice.

3. Send Existing Token: The client sends the current token (JWT) to the microservice as part of a request.

4. Token Validation: The microservice verifies the token’s integrity and validity (e.g., signature, expiration).

5. Request Token Augmentation: The microservice requests a new token with modified claims from the authentication service.

6. Augment Token: The authentication service updates the token claim (e.g., from admin to owner) based on the microservice’s request and policy checks.

7. Return Augmented Token: The updated token is sent back to the microservice.

8. Complete Request: The microservice completes the request using the augmented token and returns a secure response to the client.


Diagram



Explanation


1. Establish Secure Connection:

The client ensures all communication occurs over HTTPS/TLS to encrypt data in transit.


2. Send Existing Token:

The client includes the existing JWT as part of an API request.

The token carries claims, such as "role": "admin".


3. Token Validation:

The microservice validates the token using the public key of the issuer, verifying its signature, expiration (exp), and other claims.


4. Request Token Augmentation:

If the business logic requires a claim change, the microservice sends a request to the authentication service.


Example: Changing "role": "admin" to "role": "owner".


5. Augment Token:

The authentication service validates the microservice’s request and generates a new JWT with the updated claim. The integrity of the new token is secured using a private key.


6. Return Augmented Token:

The new token is sent back to the microservice.


7. Complete Request:

The microservice uses the new token to authorise subsequent actions or respond to the client.


Design Factors


1. Benefits:


Security: Tokens are encapsulated and validated at each stage.

Flexibility: Claims can be updated dynamically based on roles or permissions.

Scalability: Microservices maintain stateless interactions.


2. Drawbacks:

Complexity: Increases operational overhead for validation and augmentation.

Latency: Additional steps may introduce slight delays.


3. Encapsulation:

The token is encapsulated using cryptographic methods (e.g., RSA or HMAC) to protect its integrity and prevent tampering.


4. Object Nature of Tokens:

Tokens can be considered objects in OOP, encapsulating properties (claims) and methods (validation, parsing).


5. Mutability:

Tokens are immutable. When a claim changes, a new token is issued, ensuring traceability and integrity.


Further Reading


1. RFC 7519 - JSON Web Token (JWT): https://datatracker.ietf.org/doc/html/rfc7519

2. RFC 7515 - JSON Web Signature (JWS): https://datatracker.ietf.org/doc/html/rfc7515

3. O’Reilly Media, Building Microservices by Sam Newman: https://www.oreilly.com

Comments


  • Facebook
  • Twitter
  • LinkedIn

©2018 States. Proudly created with Wix.com

bottom of page