LTI Provider – Consumer Key / Secret – Not Validating

Have you ever received an error with the LTI Provider that mentions something with the ./lms/djangoapps/lti_provider/ giving you issues with the client id/secret?

2023-09-29 14:30:22,583 INFO 7 [oauthlib.oauth1.rfc5849.endpoints.signature_only] [user None] [ip] - [Failure] request verification failed.
2023-09-29 14:30:22,584 INFO 7 [oauthlib.oauth1.rfc5849.endpoints.signature_only] [user None] [ip] - Valid client: False
2023-09-29 14:30:22,584 INFO 7 [oauthlib.oauth1.rfc5849.endpoints.signature_only] [user None] [ip] - Valid signature: False

I have setup two different LTI Consumers. For some reason the one that works is the one that has consumer key/shared secret with max 20 characters, while another one with consumer key/shared secret with 30 characters seems not to work and generates the above errors.

Yes, it happened to me before we upgraded to Nutmeg and Tutor.

I still use the consumer key/shared secret with max 20 characters as a result.

I could never figure that one out.

1 Like

It may not be a character limit here for consumer key / shared secret. After debugging the POST call to https://edx-platform-lms/lti_provider with request payload value of oauth_consumer_key: fake. That’s probably why the Valid client exception was thrown.

In this case:

  • self.lti_consumer.consumer_key - Value set from the LtiConsumer model at consumer_key field. Example: 20 or 32 characters random_uuid

  • client_key - From the POST request payload value of 'oauth_consumer_key'. Example in this failing POST call is 'fake'.

So (20 or 32 characters random_uuid) == 'fake' would produce False.

In this article it talks about external app configurations created at the course-level and/or account-wide third party app configuration. I’ve always set this external app permission for EducateWorkforce at the course-level. Can you double check that you’re not setting up an external app for​ with fake​ Consumer Key value?

Confirmed this working with a Canvas customer. The had setup an External Tool at the account-level and they also had a configuration at the course-level. The course-level configuration was one that I provided for them through a IMSCC (Common Cartridge) file import, and it was never configured properly so the oauth_consumer_key: fake was getting passed from the course-level External Tool configuration instead.

When they removed the course-level External Tool configuration everything worked fine! So, I think it’s not a consumer key / shared secret length issue but rather multiple configurations of the External Tool (1 at the account-level configured properly, 1 at the course-level not setup).

1 Like

Do you have any idea what I should use (or not use) with in order to test it?


LMS Platform
The platform is using LTI version 1.2 at the moment ( edx-platform/lms/djangoapps/lti_provider/ at master · openedx/edx-platform (

Make sure LTI Provider on your platform is enabled and you generate a LTI Consumer key for testing at


saLTIre Configuration
Click on the saLTIre testing tool and perform these actions.
saLTIre: LTI Tool emulator

Click Options > Sign In to keep track of your endpoints and avoid just doing it for the session. I just login with Google.


Signature method: HMAC-SHA1 (LTI 1.2)
Consumer Key: f108ded19ac770fbe45bfff0e0169832
Secret: 7259a85faec12deb57d3f21661e132d1

Click on the Service > Tool Consumer Profile navigation item then enter in the following and then click Save.
LTI version: LTI-1p0
Note that this is the location to your LTI resource page that you’re trying to load. Mine is unique and so this should be adjusted to match your course resource location. Read more about how to build that 12.7.3. Determining Content Addresses — Building and Running an edX Course documentation here.

When you’re ready click Read then you’ll be presented if the page loaded successfully or not.

The request payload from looks like the following.

I received a HTTP 400 Bad Request call.

After I tested this, I was unable to load a page. I think that it’s due to the request payload variables not named the same as what the edX /lti_provider endpoint expects.

The following request payload needs to be there and saLTIre sends key in the payload which don’t match up with oauth_consumer_key naming. Also, the other required parameters are missing. It doesn’t appear that saLTIre can allow you to input these additional values.

# LTI launch parameters that must be present for a successful launch
    'roles', 'context_id', 'oauth_version', 'oauth_consumer_key',
    'oauth_signature', 'oauth_signature_method', 'oauth_timestamp',
    'oauth_nonce', 'user_id'

edx-platform/lms/djangoapps/lti_provider/ at master · openedx/edx-platform (

Do you have a preferred LTI launch tool that you use? I cannot get saLTIre to work with my Open edX instance.

@Zachary_Trabookis I do not have any issues using saLTIre with the shorter keys. That’s why I was asking if you did something special. I cannot even get the LMS to give me a web page when using the longer keys under Nutmeg and Tutor.

1 Like

I used Saltire to test when I was testing LTI Consumer a while back and just Canvas for the recent LTI Provider work. That’s all.