Signing users in to OneDrive (Web apps)

Article
03/05/2015

Let users sign in to their Microsoft OneDrive service from your web apps.

In this article
Prerequisites
Register your app and configure its settings
Specify a redirect domain and get a client secret

Testing web apps locally
Summary

Prerequisites

We assume that you are knowledgeable JavaScript, and can write web apps. You will also need the following:

Microsoft Visual Studio2013
Live SDK.

Register your app and configure its settings

Go to the Microsoft account Developer Center.
If prompted, sign in with your Microsoft account credentials.
If you are not immediately prompted to provide the app's display name and primary language, click Create application.
Type the app's display name and select the app's primary language.
Read the Live Connect terms of use and the Privacy and Cookies statement, and then click I accept. A client ID is created and displayed in App Settings. It should look something like this: 00000000603E0BFE.

Specify a redirect domain and get a client secret

In the Microsoft account Developer Center, select your app and click Edit settings > API Settings.
Under Redirect URLs, type the redirect domain you will be redirecting users to
Click App Settings. On the application summary page, the client secret is displayed. It should look something like this:

qXipuPomaauItsIsmwtKZ2YacGZtCyXD

Note

To change your client secret, click App Settings > Create a new client secret > OK. Both the old and new client secrets will continue to work until you activate the new client secret from API Settings in the Microsoft account Developer Center.

Here's the basic code that shows how to reference the Live SDK, invite a user to sign in, get the signed-in user's permission to get his or her basic profile info, and display a greeting with the signed-in user's first and last names. This example calls WL.Event.subscribe and WL.init to initialize the sign-in, and WL.ui to sign the user in.

default.html

<!DOCTYPE html>
<html>
    <head>
        <title>Client-Side JavaScript Code Sample</title>
        <script src="constants.js"></script>
        <script src="//js.live.net/v5.0/wl.js"></script>
    </head>
    <body>
        <div id="signin"></div>
        <label id="info"></label>
        <script>
            WL.Event.subscribe("auth.login", onLogin);
            WL.init({
                client_id: APP_CLIENT_ID,
                redirect_uri: REDIRECT_URL,
                scope: "wl.signin",
                response_type: "token"
            });
            WL.ui({
                name: "signin",
                element: "signin"
            });
            function onLogin (session) {
                if (!session.error) {
                    WL.api({
                        path: "me",
                        method: "GET"
                    }).then(
                        function (response) {
                            document.getElementById("info").innerText =
                                "Hello, " + response.first_name + " " + response.last_name + "!";
                        },
                        function (responseFailed) {
                            document.getElementById("info").innerText =
                                "Error calling API: " + responseFailed.error.message;
                        }
                    );
                }
                else {
                    document.getElementById("info").innerText =
                        "Error signing in: " + session.error_description;
                }
            }
        </script>                   
    </body>
</html>

callback.html

<!DOCTYPE html>

<html>
    <head>
        <title></title>
    </head>
    <body>
        <script src="//js.live.net/v5.0/wl.js"></script>
    </body>
</html>

constants.js (Replace YOUR_CLIENT_ID with your app's client ID and YOUR_REDIRECT_URL with your app's redirect URL.)

var APP_CLIENT_ID = "YOUR_CLIENT_ID";
var REDIRECT_URL = "YOUR_REDIRECT_URL";

Testing web apps locally

When you are developing a web app, it is convenient to test the app on a local computer before you deploy it to a web server. However, the Live Connect APIs require the redirect URL to use the same domain at which the app's client ID was configured. Your local computer's web server probably uses a default address like http://localhost, so you must map your domain to the Internet Protocol (IP) address of your local web server. To do this, you add a mapping to the hosts file on your computer. (The job of the hosts file is to map host names to IP addresses.) On Windows computers, the hosts file is located at \Windows\System32\drivers\etc\hosts. On Mac OS X and most Unix computers, it is located at /private/etc/hosts. The format is the IP address, followed by the domain to map, like this.

127.0.0.1    MyDomain.com
127.0.0.1    AnotherDomain.com

The preceding example demonstrates mapping two arbitrary domain names to the Internet Protocol (IP) address for localhost. With these mappings in place, every time you navigate to MyDomain.com or AnotherDomain.com, you will be redirected to 127.0.0.1 (http://localhost). The mappings in the hosts file apply to all web navigation, including redirect URLs that are returned by the service. This works because the service integrated with Microsoft account does not check the actual IP address that is in use, the APIs only verify the domain name. If your client ID was configured with a redirect URL of http://MyTestingDomain.com/MyApp/callback.htm, you update your hosts file with the following mapping: 127.0.0.1 MyTestingDomain.com. Now if you enter "MyTestingDomain.com" into your browser, it will resolve to http://localhost, so you can use your local web server for testing.

Note

Elevated (or root) privileges are required to edit the hosts file, regardless of platform. You can map an externally available domain to your local server IP address, but you must comment out the mapping when you want to view the actual website. This applies only to the computer on which the hosts file was modified. This is a handy trick because it makes it easy to switch between your externally available website and your local test website.

Summary

From here, we suggest starting with the info in Core concepts. If you're writing code for a server-side website or script, be sure to see Server-side scenarios, too.