0

I'm developing a website and trying to use the algorithm RS256 to generate and verify the signatures of clients (JWT).

Here is how I generate a signature at the client side (I use the Python script to simulate a client):

header = {
    "alg": "RS256",
    "typ": "JWT"
}

# Set the payload
payload = {
    'role': 'user',
    'exp': datetime.datetime.utcnow() + datetime.timedelta(minutes=1)
}

jwt_token = jwt.encode(payload, private_key, algorithm='RS256', headers=header)

http_request.add_header("Authorization", jwt_token)

As you see, to generate a JWT, I need the private key. To verify a JWT, I need the public key. (In this doc https://techdocs.akamai.com/iot-token-access-control/docs/generate-jwt-rsa-keys and the doc of Nginx https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-jwt-authentication/, they all say that using a private key to generatw a JWT and the server hold the public key to verify the siguature from the request.)

In a word, in my view, all of clients should hold the same private key to generate their signatures and the server should hold the public key to verify all different signagures.

So I'm thinking that I need to put my private key in the mobiles of clients and I store the public key in my backend server.

I've tested and it worked as expected.

But this process confused me: If I need to put my private key at the client side, does it mean that I have to hard-code the private key into the APP of mobile? Because as my understanding, sending any private key with network is dangerous...

So is there some method to allow me to send the private key to the client side safely? Or I have to hard-code the private key into the APP? Hard-code is kind of weird because if I want to update the private key, I have to force all of users to upgrade their APPs...

5
  • " trying to use the algorithm RS256 to generate and verify the signatures of clients (JWT)" - this is a purely technical description which does not provide any information about the actual use case. In general - the point of a private key is to stay private, which also means not distributing the key to the clients and especially not distributing the same key to all clients. If it is about signing client generated content, then the key pair should be generated on each client, the private key kept at the client and the client specific public key send to the server. Apr 7, 2023 at 9:47
  • @SteffenUllrich I added an example. If I understand you correctly, I have to say that generating a key pair on each client should not be possible. Because the server can't hold all of public keys of all clients. The server should hold only one key to verify all of signatures of clients. This is how I understand JWT mechanism.
    – Yves
    Apr 7, 2023 at 11:27
  • @SteffenUllrich If possible, please read this doc: docs.nginx.com/nginx/admin-guide/security-controls/… . You see, Nginx, which is the backend server, holds the public key to verify the siguature. So clients hold the private key to generate the signatures. But I just don't know how we could put the private key into the clients' devices.
    – Yves
    Apr 7, 2023 at 11:30
  • 1
    You still only provide a technical description, not an actual use case - i.e it is unclear what the purpose of the JWT is and why it should be signed by the client. It might be that what you are trying to do is the wrong approach for your use case, but again - unknown because the use case is unknown. And also again, if you share the same private key between all clients then you can hardly consider it private. Apr 7, 2023 at 11:52
  • If you have the same private key shared by all clients then at best any client can forge the signature of any other client. At worst your clients can't actually keep a secret and anyone can forge the signature of any client. Apr 7, 2023 at 19:05

1 Answer 1

3

Your example shows that users, not authentication server, will define the roles they have. This is not what JWT is used for. And all the links you provided describe another, normal scenario.

The normal scenario for using JWT is following.

There is one server that can authenticate the user. This server is called identity provider. After successfully authenticating the user this server issues a JWT token that contains user name and some claims, e.g. what roles this user has. The authentication server signs this JWT token with its private key and RS256 algorithm.

Then user calls a resource server that provides some services that user wants to use. In a request the user sends also this JWT token. The resource server first validates JWT token. The resource server is configured to trust a particular authentication server or a few authentication servers. If will not accept JWT tokens signed by random party. The resource server uses public key of authentication server and applies it according to RS256 algorithm. If the signature is valid, the resource server executes the user's request.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .