This message was deleted.
# opal
s
This message was deleted.
s
Hi @Ben Wallis great question, I will check this out with my team and get back to you cc: @Ori Shavit @Ro'e Katz
o
These are just SSH keys you generate (as described in the link you shared)
b
But what are they used for?
The link doesn't explain how they fit into OPAL's security model or what they're used for
Ah they are used for JWT signing:
Copy code
self.signer = JWTSigner(
                private_key=opal_server_config.AUTH_PRIVATE_KEY,
                public_key=opal_common_config.AUTH_PUBLIC_KEY,
o
Yes, sorry I thought that was clear to you from what you wrote
b
Ah, no - I only just found that after looking at the OPAL source, I thought they might have been but assumed if that was the case you'd need to provide OPAL Client the public key so that it could verify the JWT or something
o
They make sure only authenticated clients can use the OPAL api. This part of the docs eleborates more https://docs.opal.ac/getting-started/running-opal/run-opal-client/obtain-jwt-token
@Asaf Cohen , @Shaul Kremer Can you make a note to improve the docs here please
b
I think I understand how it works now - previously I'd (incorrectly?) assumed the master token played a part in creating the client keys, but the master token is simply a fixed auth token that OPAL Server always accepts, right? Then when you call its
/token
endpoint, it creates a new JWT (with
sub
set to a random guid?) and then signs it with the private key specified in
OPAL_AUTH_PRIVATE_KEY
. Then when OPAL Client calls OPAL Server with that JWT, it (OPAL Server) uses the key from
OPAL_AUTH_PUBLIC_KEY
to check the signature on the token was signed by itself? And OPAL Client actually never verifies the JWT signature because it doesn't care? Is that accurate?
o
Correct indeed
b
OK makes sense - thanks for the clarification 🙂 Yeah updating the docs with a similar explanation would be good I think
💜 1