Closed marcospri closed 2 years ago
seanh
commented
2 years ago I don't think we want a single global keypair to exist because the consequences of that keypair getting leaked would be too great. I think we probably want to generate a unique keypair for each deployment
marcospri
commented
2 years ago think we probably want to generate a unique keypair for each deployment
I think that sounds ideal from the point of view of the security but it might be too complex in practice.
(I apology as this background info was not in the original message)
In blackbaord (or blackboard SaaS product? not entirely sure) the app registration would only happen once. Not once per school/client/deployment but once period. The security will be configured as a one off app submission to the developer portal. That rules the one per client / deployment there.
On canvas it would be possible but the registration process would be a multi step process. We'd need a client_id to tie it to the private key, but generating a client_id needs our public key so we'd need a provisional one, get the client_id and the edit the registration with the right key again.
marcospri
commented
2 years ago My proposal would be to go for One static JWK endpoint with multiple rotating keys, that would involve:
Should we have one set of JWT per "install" or just one global one.
Canvas uses one static JWK endpoint with multiple and what it looks like a time based rolling strategy. https://canvas.instructure.com/api/lti/security/jwks
BB generates one per client_id.
This is also related to the registration process and new LTI1.3 fields on the database.
https://www.imsglobal.org/spec/lti/v1p3/impl#private-key-management https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html
Note that our (the tool's ) private keys it's only used when we initiate a communication, for example when we send a Deeplinking response message to the LMS.
Just one key
A static JWK endpoint with only one key. This is very simple but would make key rolling and phasing out impossible.
One static JWK endpoint with multiple rotating keys.
Expose only one JWK endpoint containing a set of keys. Keep an automatic rolling set of keys exposed on the endpoint and pick one and send the right "kid" when sending messages.
One JWK endpoint for install
This will require and extra step for apps registration to generate a key identifier that can be passed to the school before the tools is added to the platform. We can't use the client id as BB does as the JWK endpoint value is required before getting the client_id.
This option could be less granular than "per install". It could be 1 for "school" or one for each "LMS admin user" or similar but we don't have those concepts yet.