ScreenStepsSingle Sign-on with ScreenSteps Remote Authentication and SAML How ScreenSteps Remote Authentication WorksHow do I remotely authenticate a user using ScreenSteps Remote Authentication?

How do I remotely authenticate a user using ScreenSteps Remote Authentication?

Remote authentication is pretty simple to implement. Basically you authenticate a user on your server and then send a special string to the ScreenSteps server telling it that the user is valid. This article will explain how the string is generated.


  • You must be able to provide a URL to ScreenSteps where a user can login to your application
  • After the user logs into this page on your application you will need to generate a signed hash (described) below and redirect the user back to ScreenSteps

Information provided by ScreenSteps

When the ScreenSteps server redirects a user to your remote authentication url it sends along a couple of pieces of information in the query parameters:

  • return_to_url: This is the url that the user requested on ScreenSteps. You will pass this back to ScreenSteps after the user authenticates so that ScreenSteps can display the requested resource to the user.
  • timestamp: This is the time value that you can use when generating the MD5 hash.

The MD5 hash

The MD5 hash

In order to information ScreenSteps that a user has permission to view content you must pass over an MD5 hash. The MD5 hash is comprised of of the following strings:

  1. First name of the user (required)
  2. Last name of the user (optional)
  3. Email of the user (required)
  4. External id (used to uniquely identify user, can be empty in which case email is used, optional)
  5. Organization (optional)
  6. ScreenSteps remote authentication token (required)
  7. Time (unix time, required)



To notify ScreenSteps that a user has successfully logged in you redirect to a url and pass a number of parameters. The URL you redirect to will be the Remote Consumer URL that you can find in your remote authentication settings. An example might look like this:



You can pass the rest of the information needed as GET parameters in the query string. You must pass all of the information used to make the MD5 hash EXCEPT for your ScreenSteps remote authentication token (this must remain secret). An example:

By passing over the information used to create the hash ScreenSteps can combine the secret remote authentication token with the information you passed over in order to confirm that the hash is valid. This keeps others from being able to log users in.



Is it possible to remote authenticate a user into protected content, but instead of giving that user the url to the space in "operation mode" (I don't know how to call it), give the user the public url? The content is not public, but the public url still works if the user is logged in. In sum, I'd like to remote authenticate the user that is given a public url of a protected space. Would this work?

Blue Mango

Carlisia -

When you remotely authenticate a user we match the user up based on their email address. If you have given a user with that email address permission to view a protected space then they will be able to see the "public url".

If you a user logins using remote authentication and we don't find an email that matches for them at all in your ScreenSteps Live account then we create a new "reader" account for them. They have no access to your admin area and won't be assigned to any protected spaces. Essentially they have a reader account that only allows them to see public content.

I think the question you are asking is, can you create a new user and have them view a lesson in a protected space without first creating that user in ScreenSteps Live. Currently the answer is no. You need to create the user either via the User Provisioning API or the admin interface and assign them the appropriate space. Otherwise we have no idea what content you want them to see what content you want to hide from them.

We are looking at adding an option to pass back group information via remote authentication. That way you could just assign a group to your space on ScreenSteps Live. If the user was part of a corresponding group in your remote authentication, ScreenSteps Live would automatically log them into any protected information that group had permission to see. But that hasn't been implemented yet.

Does that all make sense?

Bill Hamaker

Is the comment that each user must be set up as a user with a Screen Steps Live account before a protected site can be integrated with a custom web site using Screen Steps Live integration still true?. Is this also true for SAML integration?

Also I see that email address is one of the parameters need to authenticate with Screen Steps Live. What if the custom web site does not track or store email addresses of the users but instead is based on user names and passwords. Is it still possible to use Screen Steps Live authentication to get single sign on?.

Greg DeVore

@Bill -
You don't have to have the user already in the system. You can set up an authentication endpoint so that a user will automatically be added to a site when they are logged in and will this have permission to view that site.

To use remote authentication you do need to send over an email address. That is what the system uses to identify the user.


Does this mean that if someone where to copy the already formed URL, they could login and bypass security ? anytime they wanted?

Trevor DeVore

@Orestes - no because they don't have your secret token. See the last paragraph in the article.

Add your comment

E-Mail me when someone replies to this comment