JWT signed with a 9c private key

[Atralupus]

To implement the controllers for NCIP 24, we need a way to verify that each request is genuinely sent by the arena participants themselves.
I’d like to use the private key that every Nine Chronicles player already has for this authentication.
By using JWT, a widely adopted method, we could encrypt a small piece of JSON with the user's private key, making authentication simple and efficient.

[Atralupus]

1. Each client generates a JWT for every request, including details like iss and exp.
2. The JWT is sent to the ArenaService via the header.
3. The service verifies the user using information in the token, such as the avatar address and public key, and allows API access accordingly.

The JSON payload will include details based on RFC 7519 Section 4.1, as shown in the example below:

{
  "aud": "arena-service",
  "sub": "0xf392d97E~~",
  "pbk": "bfcab7e8e0abac276b~~",
  "iat": 1718561199,
  "exp": 1718564799
}

sequenceDiagram
    participant Client
    participant ArenaService

    Client->>ArenaService: Send JWT in header
    ArenaService->>ArenaService: Decode JWT
    ArenaService->>ArenaService: Verify avatar address, public key, iat, and exp
    ArenaService->>Client: Grant API access if valid
    ArenaService->>Client: Deny access if invalid

Loading

[Atralupus]

#34 I will work on implementing this issue

[Atralupus]

I’ve implemented the verification code in ES256KAuthenticationHandler.cs and the generation code in JwtCreator.cs.

The JWT structure follows the standard format, including the relevant information. While the exact JSON data to include needs further consideration, the foundational code is already in place.

[Atralupus]

After discussing with the team, I received advice for a better approach than having users issue JWTs themselves.

Instead of users manually generating tokens, I will follow the standard structure where a JWT server issues tokens. However, the process for obtaining the token (similar to the login process in traditional web services) will involve users signing a specific random value with their private key and sending it.

This approach simplifies the process for users by eliminating the need to handle token issuance, expiration, and service-specific details themselves, making it as seamless as a typical web login.