This LTI® v1.3 Reference Implementation Test Tool is provided by IMS Global Learning Consortium. Limited functionality is provided free of charge. IMS Members have access to the complete functionality of the tool including services and message types. Join now to experience full functionality of the tool, technical support and certification. If you are an existing member login here for full access.

Initiating Login from Tool for Deep Link Flow

LTI Spec Notes
The parameters can either be passed as query parameters using the HTTP GET method or be passed as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method.
OpenID Connect Spec Notes
The parameters can either be passed as query parameters using the HTTP GET method or be passed as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method.
POST: Form attributes being generated:

iss: lti-ri.imsglobal.org.nightly.invalidOrg (required, the issuer identifier identifying the learning platform)

login_hint: DL1 (required, a platform opaque identifier identifying the user to login)

target_link_uri: https://lti-toolgateway-service.nightly.savvasrealizedev.com/lti_tool_gateway-service/oidc/login/authenticationResponse (required, the actual end point that should be executed at the end of the OIDC authentication flow)

lti_message_hint: 20397 (required, this is an LTI specific parameter identifying the actual message to be executed. For example it may be the resource link id when the message is a resource link request.)

lti_deployment_id: invalidOrg_depoy01 (optional, if included, MUST contain the same deployment id that would be passed in the https://purl.imsglobal.org/spec/lti/claim/deployment_id claim for the subsequent LTI message launch.)

client_id: s6BhdRkqt3.nightly.invalidOrg (optional, specifies the client id for the authorization server that should be used to authorize the subsequent LTI message request. This allows for a platform to support multiple registrations from a single issuer, without relying on the initiate_login_uri as a key)

GET: query parameters being generated:

iss: lti-ri.imsglobal.org.nightly.invalidOrg (required, the issuer identifier identifying the learning platform)

login_hint: DL1 (required, a platform opaque identifier identifying the user to login)

target_link_uri: https://lti-toolgateway-service.nightly.savvasrealizedev.com/lti_tool_gateway-service/oidc/login/authenticationResponse (required, the actual end point that should be executed at the end of the OIDC authentication flow)

lti_message_hint: 32517 (required, this is an LTI specific parameter identifying the actual message to be executed. For example it may be the resource link id when the message is a resource link request.)

lti_deployment_id: invalidOrg_depoy01 (optional, if included, MUST contain the same deployment id that would be passed in the https://purl.imsglobal.org/spec/lti/claim/deployment_id claim for the subsequent LTI message launch.)

client_id: s6BhdRkqt3.nightly.invalidOrg (optional, specifies the client id for the authorization server that should be used to authorize the subsequent LTI message request. This allows for a platform to support multiple registrations from a single issuer, without relying on the initiate_login_uri as a key)

Send Request