
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