Dov
Dov

Reputation: 8580

how to create jwk key for canvas?

In canvas, in order to have an LTI app authenticate, the site admin has enter the JWK for the remote site. The format of a JWK is well defined:

{
"kty":"RSA",
"kid":"...",
"use":"sig",
"alg":"RS256",
"n":"u6gqiV...",
"e":"AQAB"
} 

First, can we use a tool like openssl, create a key, and generate a JWK from that? Currently we are writing code to do this using jose4j but it's not even clear if that is necessary.

second, Canvas is demanding optional fields like kid, alg, and use. We guessed that use should be "sig", we made up kid: "1" and guessed alg: "RS256"

Is there a place that is accessible (ie not behind IMSGlobal's paywall) that defines what this should be? Is it standard or specific to Canvas?

Upvotes: 1

Views: 1252

Answers (2)

pfranza
pfranza

Reputation: 3367

The JWKs is a method of exchange the public keys between the tool and the platform, and to allow each side to control the rotation of their keys. The format for a JWKs is a managed ietf standard.

LTI 1.3 is based on the OIDC third-party initiation flow, which in-turn is based ontop of OAuth2. However, a full working knowledge of these specifications is not required to integrate your application with LTI 1.3. IMS curates a collection of code examples on github that might help you get started.

Upvotes: 0

kmuenkel
kmuenkel

Reputation: 2789

We meet again- been pouring over the LTI specs for months now, and am in the mood to see if I can spare others some headaches.

You may be familiar with validation schemas in which you use an SSL tool to generate a public and private key at the same time, entangled with each other. The public key is used to sign a payload, and since the payload itself is a factor in creating the signature, it cannot be intercepted and maliciously altered without invalidating it. The recipient is given the public key, used to verify that the the payload is clean.

JWK serves the same purpose as a public key. The only difference is, a developer doesn't need to email it to the recipient app's IT team in advance. The recipient of the JWT payload can retrieve it on-demand, all it needs to know is what URI to ask. That means the keys can actually be replaced by the sender without breaking any functionality.

As I mentioned elsewhere, in a bit of a rant more appropriate for this question:

This security step is akin to getting an email from your bank, and rather than click a potentially-spam link therein, you call your bank directly to make sure the email is on the level.

Now the sender's JWKS endpoint doesn't really know ahead of time who's going to reach out to it, and may want to service multiple other entities, so it may actually supply an array of public keys to cover all bases. The recipient of course only cares about the one associated with the payload it just received, so within the JWK signaure is a "kid", that can be matched up to the 'kid' in one of those array elements, affiliated with the relevant key.

How to create a JWK? Go here. Dependencies are listed at the top, and they probably use openssl under the hood.

Upvotes: 1

Related Questions