Doing User Authentication with HealthVault

My previous post with regards to writing the HealthVault Ruby Library demonstrated how one goes about authentication their application with HealthVault. Now that you have successfully gotten HealthVault to trust your application how do you make sure that the user who logs in is a valid user. In the HealthVault lingo this is called user authentication.

To successfully do a user authentication, an application must:

  • Redirect the user to HealthVault shell sign-in page.
  • Receive a token identifying the current user on a pre-registered URL with HealthVault, and use that token to do any user related transactions with HealthVault hence onwards. This token is valid for 20 minutes.

Now, in code it looks like follows lets assume that you application has a pre-registered URL of http://localhost:3000/healthvault/redirect. When a user wants to login, you actually redirect them to HealthVault shell ( in the following way:

redirect_to ""

Note the parameters target, appid & redirect in the above URL.

The above redirection once successful will send the user to the page http://localhost:3000/healthvault/redirect. On this page you should read the wctoken from the URL query-string. In ruby I do this the following way:

  def redirect
    if (request.query_parameters["target"] == "AppAuthSuccess")
      session[:wctoken] = request.query_parameters["wctoken"]
      redirect_to :controller => 'healthvault', :action => 'index'

Voila!! you have the much needed wctoken. In the next article we will what can we do with this magic wctoken!

Next time: Putting it all together!

5 thoughts on “Doing User Authentication with HealthVault

  1. A few questions:

    1. What is the difference between and https://account.healthvault-ppecom/auth.aspx?

    2. Will the production environment honor the “redirect” parameter or will it send a command to the “ActionUrl” handling page?

    3. What other “targets” are there?

    It would be really nice if someone, anyone could release some decent, reliable information on this stuff, on, let’s say, MSDN. It’s just not nice leaving the developers in the dark like this.


  2. hi Kanman:

    1. Where did you get the auth.aspx reference? The redirect.aspx is a the page handling shell targets.

    2. The production environment will not honor the redirect parameter (for security reasons) , it will send a command to the action url.

    3. The post- talks a little more about action targets. I apologize for no documentation wrt but in general for each action targerl (like sharerecord) their is a corresponding target.

    We have an upcoming open spec which should address this, we want to be open and interoperable.


  3. 1. The auth.aspx is referenced in the “Microsoft HealthVault Developers Guide Beta.xps” document shipped as part of the HealthVault SDK.

    2. Good to know. Thanks.

    3. The general information provided in that post is useful, thought it is about C# and the .NET API.

    Releasing specs would be most appreciate it. Then we won’t have to wonder about all these things.


  4. Hi Vaibhav,

    Could you confirm if my thinking is right, regarding the redirect mechanism in production?

    Our app sends a http redirection (a GET call) to HealthVault with target=AUTH and the redirect parameter pointing to our ActionURL

    When the user logs in to HealthVault, HealthVault sends a POST method to our ActionURL with target=AppAuthSuccess and the userAuthToken as values to the POST message variables, right?

    POST method is used only in Production and that too only in the return direction (HealthVault to our App), correct?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.