Moodle LTI 1.3 Access Token issue

Moodle LTI 1.3 Access Token issue

by Thomas O'Connor -
Number of replies: 15

I am developing an LTI 1.3 tool to work with Moodle. Currently whenever I try and obtain an access token from mod/lti/token.php I get back 

"error" : "invalid_client"

Using my code I have tried the same thing using the IMS Global reference and certification sites and have no issues, I get back an access code. Looking at the token.php code it looks like maybe the issue is with the decode of my client_assertion, but I am not sure. Is there any way I can turn on additional logging or debugging information so I can see more specifically why it is not working on moodle?

Tom
Average of ratings: -
In reply to Thomas O'Connor

Re: Moodle LTI 1.3 Access Token issue

by Thomas O'Connor -
So our moodle server is linux, which I dont have access to. But I thought maybe I could edit the token.php file to add some additional error handling and messaging to it to help me figure out what is going on. I had our server admin send me the token.php file, I edited the file on my Windows workstation in notepad, and sent him the file back to replace it. But whenever we did that, the server would return an error 500, internal server error, when we made the access token request to token.php. Even if all I did was change the wording of one of the error messages it has in it to make sure its the place in the code I think is failing, it would result in this error 500. Having the admin replace the edited file with the original file eliminated the error 500. Is there some special way you have to edit that file to avoid getting this?
Average of ratings: -
In reply to Thomas O'Connor

Re: Moodle LTI 1.3 Access Token issue

by Richard Oelmann -
Picture of Core developers Picture of Plugin developers Picture of Testers
Some windows text editors apply Windows specific line ending/carriage returns which then break the code. You may need to check the settings on your editor?
Average of ratings: -
In reply to Thomas O'Connor

Re: Moodle LTI 1.3 Access Token issue

by Thomas O'Connor -
I tried the same thing on a free moodleportal account. And it has the same problem. These are the private and public keys I generated to use for testing, and against other LMS's they work. But for moodle I get the invalid_client error:

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQDVPPD4jbeRca4gEWxtgAfKHVw2qvYbwMyICywQpsYVd+CyK0s9
8yYq6yyvwB4pnd6TpnnoqYaoZZSjKuZryzIZdP8UwvNWHLfD+lzujw6Vm0CRwGZE
4zR0q8M3f8k4QTgnATvrN+p3zWOeT+kVYk/YYunUf8piqSyTMJyLEaOeOwIDAQAB
AoGAEBEZbwDulezk29G0Q8Pj0lzH9+6FwK2UO6Pr3A1U24U+zu3oK3DIrW8u3Mcy
/pvAi4t9oAQ1+zY8LtcqqXCUA6e2wrp2M835ULfsfPWuidCxEB0vbUeZDrG5ZaND
hZKql+eiAtmhWM9SFyA3lYj0p4xkh1K1f3MHsLbdFu7OUiECQQD8YYaCKj+Gi9ft
87pmpB4JTC+9AaUrRr6MEMIyPImYCHyX/aJwv2W8pcp2Y2Ye9QQyTdHjoNAcCXnt
QHixy8SDAkEA2Eu5h8MPht8oo+/YfavrODiQ+FKO+NF+Z3FgbYc/Su1hgiHZcCps
9pDokiZOfxFkrGf5hnMT0eziYnm8hy3B6QJAPtgOBVV90gP6da8OCEbvj8Mf1AGX
3knUYs49fQLkBC6Az9wBWe/e5nWmD4q6wBSkwd3s2LCPgZu+d5xpMWSa/wJBAKlO
/TeMNMc6P7GzuR8GR+WGQdRfq5KRSgTm9rhFugGIt18J6A6o5wpKfAKLAb7teoSK
DwRzZ/xXFQ5IhI67/qECQBHNeDUm5Ly/QEFIuzsl7rkJR6Xjl/Cpytj7ue1OP01t
BpDtRzKXRPllZ8iH8assGCAukYfxHgs0sWpS9hoOg60=
-----END RSA PRIVATE KEY-----

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDVPPD4jbeRca4gEWxtgAfKHVw2
qvYbwMyICywQpsYVd+CyK0s98yYq6yyvwB4pnd6TpnnoqYaoZZSjKuZryzIZdP8U
wvNWHLfD+lzujw6Vm0CRwGZE4zR0q8M3f8k4QTgnATvrN+p3zWOeT+kVYk/YYunU
f8piqSyTMJyLEaOeOwIDAQAB
-----END PUBLIC KEY-----
Average of ratings: -
In reply to Thomas O'Connor

Re: Moodle LTI 1.3 Access Token issue

by Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Hi,

without knowing a little more about the exact params (client_assertion, client_assertion_type, grant_type, scope) that are being passed in the mod/lti/token.php request, it is hard to imagine what's failing exactly.

Given the error (invalid_client), it seems that the problem must be somewhere within this block of code:

https://github.com/moodle/moodle/blob/d939d6e769b213cd9ad7a86403ce8f70090470b1/mod/lti/token.php#L68-L85

So, surely there is where you should add some debugging, like error_log() calls to see them in your web server error logs.

Coincidentally... this week I've been testing some new LTI code (membership support...) involving the use of some tools out there for testing purposes and haven't got that "invalid_client" error myself (and I was using TP's public keys).

If you find yourself unable to find the exact cause and fix it... you always can fill a new issue in the Tracker, providing as many details as possible, in order to make the exact environment and, hopefully, the problem easy to reproduce.

Also, I've performed some searches in the Tracker to see if something similar has been already reported but haven't found anything, so far.

Ciao smile

Average of ratings: -
In reply to Eloy Lafuente (stronk7)

Re: Moodle LTI 1.3 Access Token issue

by Thomas O'Connor -
Thank you very much for your reply! Thats exactly what I was thinking as far as what you identified in token.php. I dont have access to the sever running moodle however I can get the server admin to send me the file, which I have tried to edit to add some more debugging code. However when I send the file back to him and he replaces it then the server returns an error 500. Even if all I did was change the wording in the error message, still the same issue. Once he replaces the edited file with the original, then everything goes back to the way it was. I am by no means a php expert, but from what I do know I should be able to edit the file like any other text file without any issues. But is there some kind of security measure thats in play? Does it check the file against something to ensure its not edited? I cant figure why editing just the spelling of a message would result in that error.
Average of ratings: -
In reply to Thomas O'Connor

Re: Moodle LTI 1.3 Access Token issue

by Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers

But is there some kind of security measure thats in play? Does it check the file against something to ensure its not edited?

Not that I can imagine, I (any dev) does that all over the time and the files are just "recompiled" and processed. Maybe there is some extension in your site configured to don't accept modifications, or requiring PHP's opcaches to be cleaned... but I really cannot imagine anything.

Maybe an alternative approach that you could follow is to install a moodle instance locally, in your computer, then use ngrok to make it accesible from outside (from your tool provider) and try to reproduce/debug locally.

Of course, the Tracker way commented above, is still available, given all the details to reproduce the problem are added there.

Ciao smile

Average of ratings: -
In reply to Eloy Lafuente (stronk7)

Re: Moodle LTI 1.3 Access Token issue

by Thomas O'Connor -

I tried to add to the tracker, it keeps telling me: Dear Moodler, before creating a new issue you need to demonstrate that you have searched among the existing issues to see if it's already been filed. Please find a similar issue from among the open issues and either start watching it or vote for it.

Ive searched for a similar issue and there were none. But it still will not let me add a new one.

In the mean time I have attached a postman script showing the exact problem I am having.

Average of ratings: -
In reply to Thomas O'Connor

Re: Moodle LTI 1.3 Access Token issue

by David Mudrák -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

either start watching it or vote for it

Try this for some other issue that might be relevant to you.

Average of ratings: -
In reply to Thomas O'Connor

Re: Moodle LTI 1.3 Access Token issue

by Benjamin Ellis -
Picture of Particularly helpful Moodlers
That could be a permission thing on the server. Your updated file probably has different permissions than the original - it mus be readable by the web server.
Average of ratings: -
In reply to Eloy Lafuente (stronk7)

Re: Moodle LTI 1.3 Access Token issue

by Thomas O'Connor -

I was able to get access to the server from the SA, and using a native editor I was able to add additional debugging code:

This is the error message I get: 

Cannot handle token prior to 20192632250-03-31T02:33:12-0500

And this is where it is happening is token.php:
if ($ok) {
$error = 'invalid_client';
$tool = $DB->get_record('lti_types', array('clientid' => $claims['sub']));
if ($tool) {
$typeconfig = lti_get_type_config($tool->id);
if (!empty($typeconfig['publickey'])) {
try {
$jwt = JWT::decode($clientassertion, $typeconfig['publickey'], array('RS256'));
$ok = true;
} catch (Exception $e) {
$error = 'error message: ' .e->getMessage();
$ok = false;
}
}
} else {
$ok = false;
}
}

Average of ratings: -
In reply to Thomas O'Connor

Re: Moodle LTI 1.3 Access Token issue

by Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Wow, that's quite a strange year (20192632250)! Sure that implies some of the time claims to fail.

Now the question is... how has JWT ended with that wrong year in the payload?

Or some of the systems have a wrong date (not likely, but possible) or, at some point, the date/payload is becoming corrupted (or being created with a wrong date).

While I'm not an expert at all... I'd try to debug in the provider how those JWT look like, just to verify if they are broken both sides... because of sure Moodle is, one of, or 1) receiving it already incorrect or 2) breaking it on decode. We need to know which one is the case.

I'm sorry I cannot share any other interesting idea... just compare the decoded content of the token @ origin and in the server, to know where the problem comes from.

Ciao smile

Average of ratings: Useful (1)
In reply to Thomas O'Connor

Re: Moodle LTI 1.3 Access Token issue

by Siddharth Patel -
Hello Thomas

I am trying to work on the same Token-based authentication and using JWT token, but can not find where to start.
Can you please help me where I should start looking for? Which Protocol on Moodle?

Thanks
Average of ratings: -
In reply to Siddharth Patel

Re: Moodle LTI 1.3 Access Token issue

by Thomas O'Connor -

If you are looking for the code moodle uses then you can find it on github. Moodle is written in php if thats what you mean by protocol.

https://github.com/moodle/moodle

Average of ratings: -
In reply to Thomas O'Connor

Re: Moodle LTI 1.3 Access Token issue

by Siddharth Patel -
Hello Thomas
Thanks for reply.

No. I meant there are several options available in moodle, like CAS, LDAP, IMAP etc.
Also, I tried to go via https://docs.moodle.org/dev/Creating_a_web_service_client

But, couldn't find any idea where can I go and start working on for the JWT token method.
One of my other web application has created JWT token and given me the key. I need to sign in the user into Moodle.
Can not understand where to start with? At which place I can get the code.
Average of ratings: -
In reply to Siddharth Patel

Re: Moodle LTI 1.3 Access Token issue

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I'm not aware of any published authentication plugins that implement JWT - searching in the plugins DB for JWT doesn't show any results ( https://moodle.org/plugins/?q=jwt ).

It is certainly possible to create an authentication plugin that works with JWT, as I've seen it done, but you're probably going to need to write code (or find someone to write code) to do it - https://docs.moodle.org/dev/Authentication_plugins might be a starting point (or looking at any of the examples in the standard auth/ directory).

Average of ratings: Useful (1)