I'm working on building a tin-can based LMS. We launch activites from the LMS according to this guide, with the appropriate query parameters for the activity to communicate back to the LRS xapi endpoint.
https://github.com/RusticiSoftware/launch/blob/master/lms_lrs.md
The thing we're struggling with is authentication of incoming statements. For now we're cheating and just using session cookies as the activities are on the same domain as the LMS, however we want to move to external activities.
I understand that tin-can prefers OAuth 2.0 for this purpose, however I'm not sure what the best token exchange flow should be. My best guess would be
- user clicks activity link in the lms
- activity url opens with tin can parameters (actor, endpoint etc)
- activity redirects user back to lrs for authentication token
- lrs redirects back to activity with authentication token plus original tin can params
- activity swaps authentication token for access token
- lrs returns access token to activity
- activity makes tin can statement calls authorised with the access token
However the first few steps seem redundant given that we're coming from the LMS/LRS anyway. Is it possible/recommended to either:
- Launch the activity with the authentication token already present in the url skipping to step 5
- Launch the activity with the access token already present in the url skipping straight to step 7
Either of these would reduce the amount of steps needed, but could introduce security risks.
Thoughts?