Thoughts on using the target_link_uri as the redirect_uri on oidc authentication request

[zluiten]

This seems a bit similar to #199, except that one is from a Platform perspective, while this issue is from the Tool side.

The problem

The platform starts an LTI message flow by sending a request to the OIDC initiation endpoint. The request gets handled by the OAT\Library\Lti1p3Core\Security\Oidc\OidcInitiator class.

This class does its thing and eventually generates a message with the necessary information to be able to redirect the browser to the configured authentication endpoint. One of the parameters set in this request is the redirect_uri, of which the specification say "One of registered redirect URIs".

This library always assumes the redirect_uri is the provided target_link_uri, but that comes with it's limitations. The target_link_uri is described as "The actual end-point that should be executed at the end of the OpenID Connect authentication flow.", but nowhere in the specification the redirect_uri and the target_link_uri are connected to each other. They are documented as separate values, but this library forces the redirect_uri to be the same as the target_link_uri.

This comes with downsides

1. When configuring a tool in a platform, the tool/content/resource URL (which becomes the target_link_uri in the LTI message) always has to be configured as a redirect URL;
2. When deploying the same tool multiple times in a platform, each with it's own tool/content/resource URL, you need to add that URL as a redirect URL to the general tool configuration;
3. As the tool provider you'll need to maintain a dynamic endpoint (since the target_link_uri can be dynamic) as the receiving endpoint of the redirect flow, while a static endpoint could be sufficient; After all, the request resource (target_link_uri) is just part of LTI message itself and the tool should redirect to it once OIDC authentication flow is finished (see target_link_id).

The solution

Do not assume the redirect_uri is the same as the target_link_uri, but treat the redirect_uri as a configurable value on the tool side. Where should this value live? There are some options:

1. As a tool application wide value.

• This value could then be injected in the OidcInitiator class and used as a value.
• Downsides: it's a breaking change because the redirect_uri is suddenly different and thus OIDC flows will fail unless platforms add/configure the new redirect_uri in the tool configuration.

2. Make it a configurable value per registration.

• This potentially allows a redirect_uri per registration. I don't know if there is a use case for that.
• Upsides:
  • no need to inject this value in the OidcInitiator class, but fetch it from the Registration entity (see code sample below).
  • easier to migrate existing configurations, since if the registration doesn't have the redirectUri parameter configured, we could fallback to using the target_link_uri as it is now.

return new LtiMessage(
    $registration->getPlatform()->getOidcAuthenticationUrl(),
    [
-        'redirect_uri' => $oidcRequest->getParameters()->getMandatory('target_link_uri'),
+        'redirect_uri' => $registration->getRedirectUri() ?? $oidcRequest->getParameters()->getMandatory('target_link_uri'),
        'client_id' => $registration->getClientId(),
        'login_hint' => $oidcRequest->getParameters()->getMandatory('login_hint'),
        'nonce' => $nonce->getValue(),
        'state' => $statePayload->getToken()->toString(),
        'lti_message_hint' => $oidcRequest->getParameters()->get('lti_message_hint'),
        'scope' => 'openid',
        'response_type' => 'id_token',
        'response_mode' => 'form_post',
        'prompt' => 'none'
    ]
);