We are demystifying the Experience API for ourselves and anyone else that wants to follow along. We began covering options for integrating a LRS and LMS in the previous article. This article will focus on using OAuth to integrate an Experience API LRS with a LMS.
We have been on a journey to understand the Experience API. We previously explored the following:
- Experience API Terminology
- Launching an Experience API Activity Provider
- Retrieving Experience API Statements from a LRS
- Recording Experience API Statements in a LRS
- Integrating a LMS and Experience API LRS with Basic Auth
We weren’t impressed with how Basic Authentication credentials could be seen in the Launch Link for an Activity Provider, so we are investigating OAuth as an alternative. There are Launch Link differences and choices to be made with OAuth for xAPI.
Launch Link Parameters
It initially seemed that inserting a program between the LMS and Activity Provider would allow generating the auth parameter for the Launch Link. We quickly realized the Activity Provider should handle authentication and signing of request to the LRS. The auth parameter is not provided in Launch Links for OAuth.
2-Legged vs 3-Legged OAuth
The xAPI specification expects the LRS to support 2-legged and 3-legged flows for OAuth 1.0. An Activity Provider might use 2-legged OAuth when user consent is not required. User consent is accomplished with 3-legged OAuth by involving users in the handshake with the OAuth endpoints on the LRS.
OAuth eliminates the passing of credentials as a parameter in the Launch Link, but other issues immediately become apparent. Consider the following points from this informative Google Groups discussion:
- The Activity Provider is expected to do the authentication.
- Activity Providers must be capable of implementing the functionality to support OAuth.
- Client-side applications will find securely performing the OAuth handshake difficult.
- Basic Authentication may be the only supported authentication mechanism by an Activity Provider.
- Learners would need an account on the LRS to authenticate if 3-Legged OAuth was expected.
Those are all great points, and there is even more to consider. The Activity Provider becomes responsible for much of the user experience with OAuth. There will likely be inconsistency in how Activity Providers handle special scenarios.
We’ve concluded the usefulness of OAuth with xAPI depends on the learning environment and Activity Providers. We could not find any sample Activity Providers that supported OAuth, but they must exist in the real world.
OAuth is a perfect fit if all of your users can authenticate on the LRS. This seems like a likely scenario for a corporate environment that intends to provide training to employees. All employees can be registered with the LRS, and the organization can require training vendors to be 3-legged OAuth capable Activity Providers.
OAuth loses much of its appeal when the user is unable to authenticate. Using 2-legged OAuth is better than Basic Authentication if you must capture the learner’s activity without involving them. This may diminish the credibility of the recorded statements though, because the actor parameter in the launch link could be manipulated. That threat could be overcome if the handoff to the Activity Provider was a form of SSO instead of a Launch Link.
Let’s return to the Google Groups discussion. There is talk around diagrams that propose issuing short-lived tokens for exchange through Basic Authentication. A variation of those diagrams might treat a Launch Link as an outbound SSO to a 3rd party LRS proxy application. Such an application would responsible for the following:
- Generate short-lived credentials for a learner’s session at an Activity Provider.
- Act as the known LRS endpoint to the Activity Provider.
- Track user sessions and tokens.
- Authenticate request from the Activity Provider.
- Relay xAPI statements to the LRS with an Activity Provider’s actual credentials.
The above is doable, but that’s a lot of work. Such an application may already exist. If so, we hope to learn about it. If not, we might attempt to create our own later. First, we should research the CMI5 standard that was mentioned in the Google Groups discussion. It appears to address a similar problem.
We really wanted OAuth to solve our concerns, but it only seems suitable for a very controlled environment. The next article in this series will explore how the CMI5 standard might assist with integrating a xAPI LRS with a LMS.
Feel free to jump ahead to other articles in this series:
- Integrating a LMS and Experience API LRS with CMI-5
- Implementing a LMS and Experience API LRS Integration
Also, definitely check out TinCanAPI.com and ADLNet.gov's xAPI standard for more in-depth details. We are just scratching the surface with this whirlwind tour, and those resources were our reference. We would like to give credit and a BIG THANKS to the maintainers of both!