Canvas LTI Authentication Timing Out

[HenryWilliamson]

I’m implementing an LTI 1.3 service and trying to request an access token from the Canvas endpoint:

POST {CANVAS_URL}/login/oauth2/token

I’m using grant_type=client_credentials and including a signed JWT in the request, as described in the OAuth2 Token Exchange documentation .

Here’s the high-level process:

• Generate a JWT with claims:

  • iss: my tool's root URL

  • sub: my registered client_id

  • aud: {CANVAS_URL}/login/oauth2/token

  • iat and exp within 10 minutes

  • jti: UUID

• Send a POST request with parameters:

  • grant_type = client_credentials

  • client_id (matches registration)

  • client_assertion_type = urn:ietf:params:oauth:client-assertion-type:jwt-bearer

  • client_assertion (the signed JWT)

  • scope including LTI AGS and NRPS scopes

The problem:
When I submit this correctly (with the real client_id and signed JWT), the request times out with no response from Canvas.
However, if I intentionally use an incorrect client_id, Canvas immediately responds with 401 Unauthorized as expected.

Additional details:

• Everything works as expected in the Canvas test environment.

• The issue only happens in our production environment, which is a self-hosted Canvas instance for my university.

Has anyone experienced this behavior? What could cause Canvas to hang on a valid client assertion request?

• Is there something specific about JWT signing or key format that could cause Canvas to hang instead of returning an error?

• Are there any Canvas logs or configuration settings we should check on a self-hosted instance?

• Could this be related to firewall, SSL, or background job settings on the production instance?

Any guidance or examples would be appreciated!

[HenryWilliamson · Accepted solution]

Solved, my flask server with gunicorn only had one worker and one thread and was dead-locked when canvas tried to access the public jwk url, just had to add another thread. It worked in test environment because the Werkzeug development server apparently handles concurrent requests.