4

This document refers to an auth token parameter being passed to the launched activity

https://github.com/RusticiSoftware/launch/blob/master/lms_lrs.md

What is this parameter, and how is it used/passed back to the LRS with statements to authorise them? The API spec only refers to OAuth which uses different parameters, and http basic auth which is username/password.

https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md#security

ricick
  • 5,694
  • 3
  • 25
  • 37

2 Answers2

3

The "auth" query string value is intended for HTTP basic auth, it's to be passed after "Basic " in the HTTP Authorization header. That's not clear at all from the document you linked, that is how current adopters have implemented it. Since Basic Auth expects a base64 encoded username/password there, in practice this means the token sent by the LMS has to be a base64 encoded username/password, but the client shouldn't have to inspect it.

Some history: I originally created this document as a proposal for how an LRS could be integrated with an LRS, and expected some rounds of feedback and improvement during the development of the xAPI spec. That hasn't happened, but in the meantime there has been demand for a way to launch xAPI content and this mechanism has been widely adopted. CMI-5 is going to include a launch mechanism, and it's using this mechanism as a starting point: https://github.com/AICC/CMI-5_Spec_Current/blob/master/cmi5_runtime.md#80-content-launch-mechanisms. CMI-5 is still subject to change, so for now folks are sticking with this launch mechanism, but not particularly interested in refining it because of the expectation that it will be replaced.

That said, the omission you brought up is severe and it might be time to add some clarifications based on how the launch mechanism is being used in the wild.

Ben.Clark
  • 146
  • 2
  • Thanks for that Ben. One strange thing in the doc you linked is this line "The LMS should limit the use of the auth value for the duration of a specific/user/learning activity/registration". If the auth value is the http basic username/password then I don't see how it's possible for the lms to "limit" the use of the token in the same way as an OAuth token. – ricick Jun 17 '14 at 01:29
  • The LMS / LRS has can inspect the statement. An example might be to create the auth token as a short lived token in a special table. This table could also identify what the actor in the statement must be and could choose to reject statements about other actors. – TJ Seabrooks Jun 17 '14 at 12:25
  • This contradicts bens assertion that the auth token is the username/password to pass back via the http basic auth header. If what you say is correct, how is the token passed back to the LRS with a statement? – ricick Jun 17 '14 at 13:50
  • 1
    These are good points, this has to be a "username/password" in the format sense, but it can still be logically handled as a token. These do not need to be usernames associated with any real user. To illustrate this point, note that the auth token in the example link base 64 decodes to ":1c0f85617508b8af461d7591e1315dd5". Which is a blank username and a randomly generated password. It's formatted as a username/password for basic auth, but the LMS can generate these for each launch and apply appropriate permissions for that launch. – Ben.Clark Jun 18 '14 at 17:39
  • That's a great idea Ben. Thanks. – ricick Jun 20 '14 at 05:56
1

Basic auth token follows standard basic auth formatting of username:password such as:

someusername:somepassword

Then base 64 encoded:

c29tZXVzZXJuYW1lOnNvbWVwYXNzd29yZA==

Prepend the word Basic and a space:

Basic c29tZXVzZXJuYW1lOnNvbWVwYXNzd29yZA==

Finally URL encoded:

auth=Basic%20c29tZXVzZXJuYW1lOnNvbWVwYXNzd29yZA%3D%3D

For example, with a SCORM cloud account you can get these from LRS section under Activity Providers. Where Key==Username and Secret==Password.

AaronLS
  • 37,329
  • 20
  • 143
  • 202