You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I connect LtiLaunche to surfconext, and ask surfconext to give me the name and email of the user, thet information never ends up in the actual LTI launch.
This is because LtiLauncher tries to get the name and email (and sub and picture) from the returned id_token. But the information by default is only available in the userinfo endpoint.
By adding a claims parameter to the authorize endpoint, th name and email are put in the id_token as well, aand everything works like it should. LtiLauncher uses a lot of scopes, but none of that information is used right now, so why not just ask for what is needed.
Hi @torinfo, I think that this could be a nice addition. I think this should be quite easy to add. I think it's fine to add a scope column to the auth_servers table and use that one in the redirect.
@StefSchenkelaars Hi, apologies. No. I don't know rails at all. I am quite familiar with a lot of differnt programming environments, but rails is not among them. Also, please note, that the claims parameter is the most important one, to make sure that the name and email end up in the login_id token. Otherwise the userinfo endpoint needs to be used to get those two claims from surconext.
If I connect LtiLaunche to surfconext, and ask surfconext to give me the name and email of the user, thet information never ends up in the actual LTI launch.
This is because LtiLauncher tries to get the name and email (and sub and picture) from the returned id_token. But the information by default is only available in the userinfo endpoint.
By adding a claims parameter to the authorize endpoint, th name and email are put in the id_token as well, aand everything works like it should. LtiLauncher uses a lot of scopes, but none of that information is used right now, so why not just ask for what is needed.
So the authorize call becomes like this:
uri.query = {
client_id: client_id,
redirect_uri: Rails.application.routes.url_helpers.launch_callback_url,
scope: 'openid',
claims: '{"id_token":{"name":null,"email":null}}',
response_type: 'code',
state: Keypair.jwt_encode(state_payload),
nonce: SecureRandom.uuid
}.to_query
on line 37 of app/models/auth_server.rb
The text was updated successfully, but these errors were encountered: