What is the legit way to get user profile information?

[DigVargasDye]

I've been barking up multiple trees trying to make sense of this.

I am setting up an LTI 1.3 tool - and while an `id_token` during launch COULD contain the user `email` (and thus give our tool a way to ID an internal user that matches) - I know a school/district using Canvas may prefer to not include this PII in the JWT. And as such I'm trying to sort out different ways to get the user information (with a Canvas admin's full permission):

1. get manual access token from admin's account to call API to get info - violates policy (https://canvas.instructure.com/doc/api/file.oauth.html#manual-token-generation)

2. advise Canvas admin to create a "limited admin" account with constrained permissions for our Tool to generate its own access token - could this violate the same policy? I can't tell

3. do the OAuth2 in-browser flow with auth code / access token dance to get "/self/user_profile" which contains the email address; requires the individual user, e.g. a student, to "authorize" this

    - asking student's authorization feels clunky UX-wise, and also I have to imagine could be confusing to a student who is not in the business of determining what data to share between Canvas and the LTI tool

    - maybe violates another policy? (having a student authorize access to the LTI tool)

4. match on provided SIS user id in LTI variable substitutions - is this possibly the only way through without violating a policy?

Any clarification folks have here on what's on the up-and-up, what's ideal in the UX, and if there's another way through I am missing?

Best,

.dig

[matthew_buckett]

Although the administrator would prefer not to include personal information in the JWT this is a very clean solution as it only gives you personal details about people who actually launch the tool (so if it's just used by 1% of users you don't get details of the other 99%). It allows you to finely limit the information you pass over (for example you can elect to send a users full name but not the email address). Even if you need to enable Names and Roles Provisioning on your LTI Developer Key that only allows you to list the users in the courses the tool is enabled in and again it just gives you the details your allowed to see.

You suggested solutions:

1. Using a single token for all users (an admin token) is done by lots of tools, (for example Panopto) and I don't believe is against Instructures policy. This isn't a good solution though as the admin token allows you to see all details of all users and also allows you to do things you don't need access to.
2. This is a little better, but it still gives you much more access than you need (eg access to users who have never used your tool).
3. Doing OAuth is confusing for users and you end you losing some of the benefits of LTI integrations (seamless authentication).
4. I don't quite follow what you're suggesting here.

Attempting to "match up" accounts can be tricky, if a user doesn't match is the plan to do just in time provisioning of a user account? 

[DigVargasDye]

Yes - the best solution would certainly be the customer sending us `email` in the `id_token` - which we will be strongly encouraging and asking for.

BUT I am also aware of a security concern in doing so. Since the `id_token` is an easily unpackable JWT, I want to account for the sensitivity around having PII in it and the possibility that a school/district may have a policy against putting PII in a browser redirect.

Most particularly, since the Implicit Flow (what LTI launch uses) is via a browser redirect, this means that the JWT can live for quite a long while in someone's browser history. For this reason, much of the OAuth2 world has moved on from and discouraged Implicit Flow: (references here , here and here )

While we are not dealing with access tokens, we are dealing with the PII of students (minors). And so having in our back pocket a means of getting user `email` from the more opaque Canvas user_id / `sub` without it persisting in someone's browser history (a known vulnerability of implicit flow) would be ideal.

[DigVargasDye]

Regarding #4 - we could match accounts based upon user_sis_id (which we have from rostering) if we configure our tool to use LTI Variable Substitutions (https://canvas.instructure.com/doc/api/file.tools_variable_substitutions.html) but that could be more painstaking data munging / may lead to more mismatches.