Existence of userinfo endpoint? Or another pathway to get name/email not in LTI id_token redirect?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I am currently configuring my Tool for LTI 1.3. I have a successful pathway to init and launch between our sandbox account and the prototype. 🎉
I see that the id_token's content are dependent on the privacy settings of the integration, which would be setup school-by-school. I know for your Tool's placements/deployments we could set our JSON config to `"privacy_level": "public",` or `"privacy_level": "email_only",` and provide a configuration url to schools/districts so enforces that an `email` claim is present (rather than giving them a pasteable JSON blob).
However, both because I could see a school/district strongly preferring otherwise, and because we may not want PII to be in a query string's id_token - we would like to plan for the eventuality that we would only receive the `sub` / CanvasUserId, which is of course opaque for us.
What is the pathway to get these claims in a server-to-server call instead with the provided canvas user id? Looking for the equivalent of a "userinfo" endpoint (per oidc: https://openid.net/specs/openid-connect-core-1_0.html#UserInfo).
I DO see there's documentation here: https://canvas.instructure.com/doc/api/file.oauth_endpoints.html#get-login-oauth2-auth that mentions what seems to be a "userinfo" flow, but I'm somewhat confused by the docs.
Are the example responses for the GET call or the POST call (they seem mixed together in the doc)? I am assuming we will need to do a GET with the userinfo scope for the auth code followed with a POST with the code? Does this require also configuring an "API developer key" for each integration that a school sets up (in addition to the LTI Developer key) to initialize getting the `code`? Is there any code challenge / PKCE to this flow, or is providing the code directly sufficient?
Best,
.dig
