Configuring LTI 1.3 in Moodle

LTI 1.3 is the standard that lets one system launch learning content that lives in another. A learner clicks a link in the system they already use, and a course or activity hosted elsewhere opens for them as though it were local, carrying their identity across and sending their grades back automatically. That lets you bring in a course another organization hosts, or share a course you host so that partners’ learners can take it without leaving their own environment. Both systems can be Moodle, but they do not have to be: the other end could just as easily be a different LMS or a specialist content or assessment provider.

Whichever direction you are setting up, it works the same way once you know which side plays which role, and the single most common reason a setup goes wrong is that the two roles, Platform and Tool, get swapped. This guide focuses on the Moodle side of the connection. It anchors that distinction first, then walks through registration, publishing, adding the launch link, and the launch errors you are most likely to hit.

Platform and Tool: the distinction everything depends on

The clearest way to hold the two roles in your head is to ask which site hosts the content and which site launches it.

• The Tool is the site that hosts the content. It owns the course or activity and delivers it when it is launched.
• The Platform is the site that launches the content. It is where the learner sits and clicks the link to open that course or activity.

The reason this trips people up so often is that the names feel backwards. “Platform” sounds like the big, primary system and “Tool” sounds like a small add-on, so the instinct is to make your own main Moodle the Platform and treat the other site as the Tool. But the roles are defined by who owns the content, not by which site feels more important. The Tool owns and serves the activity; the Platform is simply the place learners launch it from, which is usually your own everyday Moodle.

It helps to remember the older LTI 1.1 names, because they describe the roles more plainly. The Platform used to be called the Consumer, and the Tool used to be called the Provider. The Provider provides the content and the Consumer consumes it. If you keep “provider is the Tool” and “consumer is the Platform” in mind, the direction stops slipping.

LTI 1.3 term	Old LTI 1.1 term	What it does
Tool	Provider	Hosts the course or activity and delivers it when launched
Platform	Consumer	Where the learner clicks the link to launch it

The roles work the same way whatever sits on the other end, but they are easiest to lose track of when both sides are Moodle, because then nothing in the interface reminds you which role a given site is playing. You have to decide it and hold onto it. Everything else follows from that one decision, including the single rule that causes the most failed setups: the registration URL is generated on the Tool and pasted into the Platform, never the other way around. Generate it on the wrong site and the registration will not describe the two-system relationship you meant to set up, so it usually fails outright, often with a message about the result not being valid JSON or the host being blocked. Pasting a site’s own registration URL back into itself is a special case: it configures Moodle against itself, which is only useful if you are deliberately testing both roles on one site. In a real two-system setup it almost always means the direction has been lost.

This is the most common source of LTI 1.3 pain, and it plays out regularly in the community. In the moodle.org forums you will find launch and registration failures that look like certificate or JSON problems but come down to a reversed Platform and Tool assignment. Before you debug certificates, cookies, or firewalls, be certain which site is which.

The rest of the LTI 1.3 vocabulary

A few more terms come up during setup. You do not need to master them, but recognizing them makes the error messages easier to read.

• Registration is the trust relationship between the Tool and the Platform. It is set up once, either dynamically or by hand, and it is what lets the two sites believe each other’s messages.
• Deployment is a specific activation of the registered Tool inside the Platform. It identifies a trusted launch context, and dynamic registration normally creates it for you. It is separate from the actual course or activity you publish, which you select later through Content Selection or through the published content’s Launch URL and custom properties.
• Launch is the moment a learner clicks the link on the Platform and is carried into the Tool’s content.
• Line items and scores are the part of the standard that sends grades from the Tool back to the Platform.

Decide the direction before you touch a setting

Before changing anything, work out which side is the Tool and which is the Platform. Throughout this guide, Moodle A is the Tool (it hosts the content) and Moodle B is the Platform (it launches the content). The walkthrough shows both sides as Moodle because that is the case you can configure end to end yourself, but the other end is just as often a non-Moodle system. When it is, follow the Moodle-side steps here and use the equivalent screens on the other platform. Either way, your situation is one of two directions.

You are consuming content from another provider. Your learners live in your Moodle, but the course is hosted elsewhere, whether that is another Moodle, a commercial content provider, or a specialist tool. The other system is the Tool, your Moodle is the Platform, and the registration URL must come from the other system and be pasted into yours.

You are providing content to another organization. The course lives in your Moodle, but learners launch it from a partner or customer platform, which may or may not be Moodle. Your Moodle is the Tool, their system is the Platform, and you generate the registration URL and hand it over for their administrator to paste into their platform.

Requirements

Any LTI 1.3 setup assumes both sides can reach each other as real servers over HTTPS. In most cases that means public URLs with valid certificates. Private, VPN, or staging URLs can work too, but only if each server can actually resolve and reach the other and Moodle’s blocked-host settings permit the connection. In practice that means:

• Both sites use HTTPS with certificates each server trusts.
• Each server can actually reach the other’s domain. The usual culprits when this fails are URLs the other side cannot resolve or connect to: localhost, private IP ranges, VPN-only hostnames, or staging URLs that are not reachable from the other server.
• When your Moodle is the Tool, it needs both the LTI authentication plugin and the Publish as LTI tool enrolment plugin enabled. Moodle requires the authentication plugin alongside the enrolment one; it is how remote learners are provisioned an account on the Tool.
• When your Moodle is the Platform, it needs the External tool activity available.
• Whatever runs on the other end must be LTI Advantage compliant, and ideally supports dynamic registration.

Step 1. Enable LTI on the Tool site

Do this on Moodle A, the site that will host and deliver the content.

1. Log in as an administrator.
2. Go to Site administration > Plugins > Authentication > Manage authentication and enable LTI.
3. Go to Site administration > Plugins > Enrolments > Manage enrol plugins and enable Publish as LTI tool.
4. Optionally, open Publish as LTI tool > Settings to review the defaults, including the provisioning mode that controls how remote learners get an account.

If you want the Tool to display inside an iframe on the Platform rather than in a new window, also enable Site administration > Security > HTTP security > Allow frame embedding. Depending on browser cookie behavior, iframe launches may still need extra cookie configuration, which is covered in troubleshooting.

Step 2. Register the Tool with the Platform

Dynamic registration is the simplest way to exchange the LTI 1.3 configuration between the two sites. You start on the Tool, finish on the Platform, and confirm back on the Tool.

This walkthrough uses dynamic registration, which is the recommended path whenever both sides support it. Manual registration is also possible, but it means exchanging the issuer, client ID, authentication and token URLs, public keyset (JWKS) URL, redirect URLs, and deployment ID between the two systems by hand. Use it only when the Platform cannot do dynamic registration.

On Moodle A, the Tool

1. Go to Site administration > Plugins > Enrolments > Publish as LTI tool > Tool registration.
2. Click Register a platform.
3. Enter a Platform name that will remind you which site it is, for example the customer or organization name, then click Continue.
4. On the Tool details tab, copy the Registration URL shown under Dynamic registration.

That URL belongs to the Tool. It is meant to be entered on the Platform, and nowhere else.

On Moodle B, the Platform

1. Go to Site administration > Plugins > Activity modules > External tool > Manage tools.
2. Paste the registration URL into the Tool URL or Add tool field at the top of the page, depending on your Moodle version.
3. Click Add LTI Advantage. Moodle contacts the Tool, exchanges keys, and imports the configuration.
4. The tool appears in the list, often as pending at first. Review its settings and activate it.

Confirm the registration on Moodle A

Return to Publish as LTI tool > Tool registration on the Tool. The registration should now show as active, with the Platform details and a deployment stored automatically. With dynamic registration you normally do not need to edit the platform or deployment details by hand.

Step 3. Publish a course or activity from the Tool

Registration establishes trust between the sites, but it does not yet share any content. Do this on Moodle A to expose a specific course or activity.

1. Open the course you want to share.
2. From the course navigation or More menu, choose Published as LTI tools or Publish as LTI tool, depending on your Moodle version.
3. On the LTI Advantage tab, click Add.
4. Under Tool to be published, select the course or activity.
5. Enable grade sync and user sync if you need them, and optionally set a maximum number of enrolled users.
6. Save. Moodle now shows a Launch URL and a Custom properties value for this published content.

Copy the Launch URL and the Custom properties value. You will need them if you add the link on the Platform by hand. The custom properties identify exactly which published item to open, and look like this:

id=fe3dfbec-bd5b-4532-8bd5-0804a7102631

Step 4. Add the launch link on the Platform

There are two ways to place the link on Moodle B. Content Selection is the cleaner option when the teacher on the Platform can log in to the Tool and pick the content interactively. Manual link creation is for when you need to hand someone a fixed launch URL and property value instead.

Preferred: Content Selection

1. Confirm the registered tool is active on the Platform.
2. In the course where the link should appear, add an External tool activity, or pick the preconfigured tool from the activity chooser.
3. Click Select content.
4. If prompted, log in to the Tool and link the account.
5. Choose the published course or activity, add it, then save and launch.

This is usually the cleanest route because Moodle fills in the correct launch parameters for you. It does require the person creating the link to have, or be able to create, an account on the Tool site. If that is not possible, use manual link creation instead.

Alternative: manual link creation

Use this when Content Selection is not practical, for example when another administrator sets up the link without access to the Tool. On the Platform:

1. Add an External tool activity and choose the registered Tool.
2. Enter an activity name, and paste the Launch URL if Moodle asks for it.
3. Expand the advanced settings and paste the full Custom properties value into Custom parameters.
4. Save and launch.

Copy the custom properties exactly. Do not confuse the published content id with the LTI deployment ID; they are different values, and Moodle labels each where it means it.

Step 5. Test the launch

Test as a normal learner, not only as an administrator, because provisioning and permissions behave differently for the two.

1. Log in to the Platform as a test learner and open the course.
2. Click the External tool activity and confirm you land in the Tool’s content.
3. Check that the correct course or activity opens.
4. If grade passback is enabled, complete something and confirm the grade returns to the Platform. Passback can be asynchronous, so it may arrive after a scheduled task runs rather than instantly.
5. If user sync is enabled, confirm the learner is provisioned or linked as expected on the Tool.

Troubleshooting

“The result was not valid JSON” during registration

This appears during dynamic registration when Moodle expected an OpenID configuration in JSON but got something else. The full message usually reads along these lines:

There was a problem fetching the OpenID configuration from the platform.
The result was not valid JSON.
This may also be caused by blocked hosts configuration.

The most frequent cause is the direction mistake from the top of this guide: the registration URL was generated on the wrong site, or pasted back into the same site. Confirm that the URL came from the Tool and went into the Platform. After that, check the other common causes:

• One of the URLs points at localhost, 127.0.0.1, or a private range such as 10.x.x.x, 172.16.x.x to 172.31.x.x, or 192.168.x.x, which the other server cannot reach.
• Moodle’s blocked hosts or cURL security settings are preventing the server-to-server request.
• The remote site answers with a login, SSO, maintenance, WAF, or error page instead of the expected JSON.
• HTTPS is broken, or the certificate is not trusted by the other server.
• The registration URL is stale. Delete the partial registration and generate a fresh one on the Tool.

Invalid launch data: custom claim ‘id’ missing

The Platform launched the Tool without the custom parameter that says which published content to open. On the Tool, copy the Custom properties value from the published content, then on the Platform edit the External tool activity and paste it into Custom parameters. Save and launch again.

Unable to find deployment

The Tool received a launch for a deployment it does not recognize or trust. Confirm the registration is active on the Tool, that the deployment exists under it, and that the Platform is using the correct registered tool. If you created several similar tools, make sure the Platform is not pointing at the wrong one. Dynamic registration normally creates the deployment automatically, so if it is missing, re-running registration usually restores it.

JWT signature or key errors

A JWT or key error means Moodle cannot validate the signed launch message. The usual culprits are a keyset URL that is unreachable, or a registration that was partly deleted or recreated on only one side. Confirm both sites use the correct registered tool, that the JWKS keyset URLs are reachable, and that no proxy, firewall, CDN, or WAF is blocking them. If in doubt, remove the registration on both sides and run dynamic registration again from scratch.

No grades are returned

Grade passback has several switches that all have to be on. Check that grade services are enabled in the Tool registration, that the External tool settings on the Platform accept grades, and that the published content on the Tool has grade sync enabled. Then confirm the launched activity actually produces a grade and that Moodle’s scheduled tasks are running, since passback is often processed asynchronously rather than at the moment of completion.

The Tool will not display inside an iframe

If the launch works in a new window but not embedded in the course page, the problem is almost always iframes or cookies. Confirm Allow frame embedding is enabled on the Tool, that both sites use HTTPS, and that the browser is not blocking the third-party cookies the session needs. Some setups require the session cookie to be marked for cross-site use:

SameSite=None; Secure

Only apply that change once you understand the security implications, and test it on staging before touching production.

A quick diagnostic checklist

When a registration or launch fails, run down these questions before anything else. Most of them come back to the Platform and Tool distinction.

• Which site is the Tool, and which is the Platform?
• Was the registration URL generated on the Tool and pasted into the Platform?
• Can each server reach the other’s domain over HTTPS, and is that URL resolvable from the other server?
• Is either site using localhost, a private IP, or a VPN-only hostname?
• Is Moodle blocking the host through HTTP security or cURL blocked-host settings?
• Is the registered tool active on the Platform, and the registration active on the Tool?
• Was the course or activity actually published on the Tool?
• For manual links, were the custom properties copied into custom parameters exactly?

Summary

Get the roles right and the rest of LTI 1.3 falls into place. The Tool hosts the content. The Platform launches it. The registration URL always travels from the Tool to the Platform. Most confusing setup failures are one of three things: the two roles reversed, a URL the other server cannot reach, or the published content’s custom property mixed up with the deployment ID. Decide the direction first, and you will avoid nearly all of them.

Solin specializes in Moodle integrations and LTI content delivery, connecting Moodle to other platforms in either direction, whether the other end is Moodle, another LMS, or a specialist content or assessment tool. If you need a setup configured or a stubborn launch error diagnosed, we can help.

Integrating external tools at scale? Solin offers Moodle integration services covering LTI, web services, and custom connectors, delivered as a fixed-price project.