We're integrating an LTI 1.3 tool with a d2l-partners.brightspace.com instance and hitting a consistent failure at the OIDC authentication step. Posting here before contacting partner support in case anyone has seen this pattern.
What happens
The OIDC login initiation works correctly — Brightspace POSTs to our /login endpoint, we build the auth redirect with all required parameters and send the browser to /d2l/lti/authenticate. Instead of form-posting the id_token back to our redirect URI, the auth endpoint immediately returns a 302 to an error page:
/d2l/error/404/log?targetUrl=http://[instance]:80/d2l/lti/authenticate?[same params]
The targetUrl in the error redirect is our original request URL but with http:// and :80 substituted for https://.
Parameters we send to the auth endpoint
response_type=id_token
response_mode=form_post
prompt=none
scope=openid
client_id=…
redirect_uri=https://[our-tool]/api/lti/launch
login_hint=...
state=...
nonce=...
lti_message_hint=...
What we have ruled out
- redirect_uri matches the registration exactly
- client_id and deployment ID match the registration
- Tool registration is enabled
- Tested both iframe (with lti_storage_target) and new window (without) — same result both ways
- Removed Keyset URL and NRPS from the registration — no change
- D2L System Log on the instance shows no entries at all for these attempts
- Our server logs confirm the login route receives the request and issues the redirect correctly every time
What the error URL suggests
The instance sits behind a load balancer that terminates TLS, so internally the app server sees http://. The http://:80 in the error's targetUrl looks like Brightspace is constructing an internal redirect URL using the raw app-server base URL rather than the external HTTPS URL. We suspect this is a misconfiguration specific to the LTI auth endpoint on this instance rather than anything in our tool, but we'd like to rule out the tool side first.
Has anyone seen this pattern on a d2l-partners hosted instance? Specifically the http://hostname:80 appearing in the error redirect URL? Any known instance-level config that affects how the auth endpoint constructs internal URLs?
