Learning Tools Interoperability (LTI) is an open framework for building third-party integrations in learning management systems. While Classroom add-ons and LTI tools support similar user journeys, the two frameworks are not directly compatible. This guide compares the two integration types and highlights key differences. It also suggests ways to achieve similar user journeys when adapting an LTI tool to work as a Classroom add-on.
Interactions between platform and tools
A key distinction between LTI tools and Classroom add-ons is the
manner in which information is exchanged. LTI tools typically use HTTP POST to
transmit payloads to an LTI platform, while Classroom add-ons
create and retrieve resources using the Google Classroom REST API.
The following table summarizes how to achieve key LTI tool behaviors with Google Classroom.
| Feature | LTI | Classroom |
|---|---|---|
| Create assignments | Assignment & Grade Services | Create CourseWork and AddOnAttachment resources |
| Post grades | Assignment & Grade Services | Patch CourseWork and AddOnAttachment student submissions |
| Launch routes | Deep Linking | Specify URIs in AddOnAttachment resources |
| Read course rosters | Names & Role Provisioning Services | Retrieve Student and Teacher profiles in a course |
Adapt an LTI tool to Classroom add-on
Many LTI interactions have analogues in the Classroom add-ons framework. The following sections discuss some key concepts and recommended courses of action.
Configure your application
All programmatic interactions with Google Classroom require a Google Cloud project. You'll configure your application listing in the same Cloud project, which defines how your Classroom add-on will appear to end users. You'll provide icons, set the app name and description, and configure the OAuth scope permissions that your product requires.
Installing your add-on application from the listing is often the only configuration step that end users must perform. This is analogous to enabling and deploying an LTI tool. End users won't need to complete any registration actions or manage any configuration details, though an administrator might need to allow the app in the Marketplace and configure third-party data access permissions.
Recommendation: Follow our guide to creating and configuring a Google Cloud project for a Classroom add-on. Most importantly, specify a URL for the add-on launch as the Attachment Discovery URI in the Marketplace SDK. This URL can be the same as an existing LTI tool launch route as long as it routes the user to the appropriate authentication flow.
Authentication flow
LTI uses a 2-legged flow in which a client application and authentication server exchange a signed JWT. Users don't need to grant a tool access to their data, as consent is implied when an administrator configures the tool.
In contrast, Google's OAuth flow is a 3-legged flow, involving the end user, external client application, and authentication server. The client receives tokens with explicit user consent that grant access to the user's Google Classroom resources.
It is possible for a add-on application to achieve similar 2-legged signed-JWT behavior using service accounts. These are accounts that belong to an application instead of an individual user and can take action without user consent. Use of service accounts requires administrator configuration and management. Usage of service accounts with domain-wide delegation is strongly discouraged, as they are potential abuse vectors. See our guide to domain-wide delegation with Google Classroom integrations for more details.
Recommendation: When a URL associated with your tool or add-on receives an incoming request, inspect the request for the presence of Classroom add-on query parameters. If present, use the Google Identity SDK to obtain access credentials for the user. Store the credentials in the user's session and use them to make subsequent Classroom API requests. If the query parameters are not present, use HTTP requests to interact with the platform's LTI endpoints.
Creating add-on content in Google Classroom
Classroom add-ons support one type of content: URL links to pages
hosted externally. These links are contained in AddOnAttachment resources,
which define the web routes to open when a user interacts with your
add-on. Each URL opens in specific scenarios, see our
iframes guides for full details. These URLs are analogous to LTI Resource
Links.
Classroom add-ons don't support other content types such as files, images, or HTML fragments.
Recommendation: When a user selects content in your product, obtain their
OAuth credentials and make an AddOnAttachments.create request. The request
should contain an AddOnAttachment object containing the URLs for a student
view, a teacher view, and (optionally) a grading view. Note that there are
separate API endpoints for creating attachments on announcements,
assignments, or course materials. Only attachments
created on assignments can have the grading view, as this is the only type of
Classroom stream item that accepts a student submission.
Framework feature comparison
Integration placements
Classroom add-ons create attachments on announcements, assignments, and course materials. These are the items that appear in a course's Stream tab in the Classroom UI.
Teachers start the add-on attachment creation journey by selecting an add-on in a picker in the assignment creation flow. See the iframes guides for detailed discussion of each view presented to users.
Alternatively, developers can programmatically create assignments with add-on attachments. See our guide to creating attachments outside of Google Classroom for details.
Launch context information
Classroom appends several query parameters to each URL when opening an add-on route. These always include the stream item type and identifiers for the course and stream item. Other information may be present depending on the iframe view, such as the attachment or submission identifiers, a token to authorize attachment creation, or the URL to upgrade from a link to an add-on attachment.
Classroom does not pass any information about the user or institution by default. You can obtain information about the user from the Classroom API UserProfile resource, including a user ID. If the user is a domain administrator, you can obtain information about the institution from the Workspace Admin SDK.
Authentication and authorization
Classroom add-ons must use Sign in with Google for user authentication. Once signed in, users grant permission to your application through OAuth 2.0 scopes. Your application can use any combination of available OAuth scopes.
App discovery and configuration
Users find and "install" Classroom add-ons through the Google Workspace Marketplace. The one-click installation makes an add-on application available to an individual teacher. Optionally, an administrator can install the add-on application for all teachers in an organizational unit or domain. Attachments made with the application are then accessible by all students in a course. There is no need for end users to manage tokens, keys, or identifiers for individual Classroom add-ons.
UX and product flow
In many cases, an LTI tool's existing product flow works well as a Classroom add-on. Similar to an LTI tool, a Classroom add-on essentially lets you create and manage links to your content on our platform. Classroom add-on attachments are similar to LTI Deep Linking links. If your LTI tool creates URLs that point to your hosted content, it should work well as a Classroom add-on.
Grade student work
Classroom add-on attachments can be viewed and graded in the
Classroom grader view. When attaching content that requires a
student submission, you provide a student_work_review_uri where an instructor
can view and grade the work from a particular student. This is different from
LTI, where a tool only defines a target_link_uri that is common to both
teachers and students. The Classroom add-ons implementation is
most similar to the upcoming LTI Submission Review Service.