BigBlueButton LTI integration, from standard to working classroom

01

What Learning Tools Interoperability actually does

Learning Tools Interoperability is a 1EdTech technical standard for connecting a learning platform to a remote tool without a second login. In a BigBlueButton deployment, the LMS is the LTI Platform (historically “Tool Consumer”) and the broker/rooms application is the LTI Tool (historically “Tool Provider”). A launch can carry a stable user identifier, course context, resource link and roles; the tool validates that launch, applies its own policy and sends the user into the appropriate classroom. LTI is not media transport, user-directory synchronization or proof that recordings and grades will return automatically.

• The LMS remains the source of course membership and launch context.
• The LTI layer validates the launch and maps LMS roles to room permissions.
• BigBlueButton still handles meetings, WebRTC media and recording processing.

02

LTI 1.1, LTI 1.3 and LTI Advantage are not interchangeable

Legacy LTI 1.0/1.1 launches use an OAuth 1.0-style consumer key and shared secret. LTI 1.3 replaces that model with OpenID Connect login, OAuth 2.0 and signed JSON Web Tokens backed by public keys. LTI Advantage is the collection of optional services built around LTI 1.3: Assignment and Grade Services (AGS), Names and Role Provisioning Services (NRPS), and Deep Linking. A tool can accept an LTI 1.3 launch without implementing every Advantage service.

03

Install the BigBlueButton LTI components

BigBlueButton documents two applications: bbb-lti-broker accepts and validates incoming LTI launches; bbb-app-rooms provides the educator/student room interface and calls the BigBlueButton API. On the supported bbb-install release branch, the -t option installs the LTI framework and adds or updates a consumer key pair. Generate a dedicated high-entropy secret, use a maintenance window and copy the exact current command from the official release documentation rather than an old blog post.

1. 1

   Confirm BigBlueButton is healthy with sudo bbb-conf --check and back up the current application configuration.

2. 2

   Generate a unique LTI consumer key and a long random secret; do not reuse the BigBlueButton API shared secret.

3. 3

   Run the current bbb-install command for the installed BBB release and append -t KEY:SECRET.

4. 4

   Open https://bbb.example.org/lti and confirm the broker endpoint responds over a trusted TLS certificate.

5. 5

   Keep the LTI secret in the LMS secret store and password manager; never place it in a course page or browser script.

sudo bbb-conf --check
openssl rand -hex 32
wget -qO- https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh \
  | bash -s -- -v jammy-300 -s bbb.example.org -e admin@example.org -w \
  -t LMS_KEY:LONG_RANDOM_SECRET

04

Register the LMS and map classroom roles

For LTI 1.0/1.1, the broker repository documents a tool URL ending in /lti/TOOL_NAME/messages/blti plus the consumer key and shared secret. LTI 1.3 is a manual, multi-party registration: the LMS supplies issuer, client ID, authentication, token and key-set URLs; the broker supplies login, redirect and public-key details. The current broker README is authoritative for those routes. After registration, explicitly decide which LMS roles become BigBlueButton moderators.

1. 1

   Choose LTI 1.1 or 1.3 from a written compatibility matrix for the exact LMS and BBB LTI component releases.

2. 2

   Register the tool in a sandbox tenant/course and exchange only the values required by that version.

3. 3

   Map Instructor, Faculty or Teacher to moderator only where institutional policy agrees; keep Learner as viewer.

4. 4

   Limit personal data and optional services to the approved educational purpose.

5. 5

   Test clock synchronization, key rotation and the exact redirect/launch URLs before opening access.

05

Common problems and practical fixes

A useful acceptance test covers more than a teacher launch. Test an enrolled learner, teaching assistant, unenrolled account, copied course and expired registration. Inspect server logs without recording tokens or personal data. For a legacy launch, the TSUGI test page linked by BigBlueButton can help isolate signing problems; for LTI 1.3, validate OIDC state/nonce, issuer, audience, deployment ID and JWKS retrieval.

• 401/signature failure: compare normalized launch URL, consumer key, shared secret and server clocks.
• LTI 1.3 login loop: inspect OIDC initiation URL, redirect URI, cookies, state and nonce.
• Unknown deployment/client: finish both halves of the manual registration and enable the client.
• Wrong BBB privileges: review the incoming role claim and BIGBLUEBUTTON_MODERATOR_ROLES.
• Blank iframe: inspect Content-Security-Policy, X-Frame-Options and third-party-cookie behaviour.

06

Platforms that can use the BigBlueButton LTI route

Use LTI where the platform has no stronger native BigBlueButton connector or where the institution deliberately standardizes external tools. Moodle’s core BigBlueButton activity and Canvas Conferences may be better-supported product paths than replacing them with generic LTI. Open edX, Brightspace and Schoology are the clearest candidates in this library; Jenzabar requires release-specific confirmation. The guides below turn the shared architecture into platform-level checks.