Web Service Security for Windows Phone

Authentication is the process of asserting to another application your identity as a program or as a user of a program. It also applies in the other direction. For example, although you might make a request of a shopping website, the HTTPS protocol requires the website to provide your web browser with proof – called credentials or claims – that the website is who it says it is.

If the data that your application needs to obtain has some value, the web service that provides it is likely to ask you to authenticate yourself – that is, “log in” as a client – to establish whether you should have access to the data.

In this release, Windows Phone supports Basic Authentication to establish an identity. Basic Authentication is a simple protocol, requiring a username and password (base64-encoded to enable characters that are not supported by HTTP) to be sent to a website or service. Basic Authentication, however, does not encrypt the username and password for security purposes; therefore, the following point is extremely important:

Important Note:

Because Basic Authentication does not encrypt the username and password data, unless you encrypt the data or the stream yourself, an interceptor of the HTTP request can decode the username and password, and your application could unintentionally expose your application account or the user’s account to damage. We therefore strongly recommend that you use Basic Authentication with the HTTPS protocol, which encrypts communication for data protection. For more information about HTTPS, see the following section on protecting communication.

You can also use other authentication protocols to assert the identity of your application or of the user of your application over HTTP (and HTTPS). For example, some web services require OAuth 1.0, although, because it does not require an encrypted connection, the previous warning still holds true: We strongly recommend that you use an encrypted connection such as HTTPS with any unencrypted authentication protocol. For more information, see OAuth home page and OAuth 1.0 Protocol.

Windows Phone supports other communication options in addition to HTTP. (For more information, see Sockets Overview for Windows Phone.) Typically, however, your authorization mechanism is implemented with the HttpWebRequest and WebClient classes, or with specialized classes provided by other libraries, many if not most of which are built using those classes. For example, the OData Client Library for Windows Phone helps you use HTTP to obtain data from an OData service without using either of these classes directly. For an example of using this library, see How to: Consume an OData Service for Windows Phone.

The HttpWebRequest and WebClient classes restrict access to some HTTP headers; for more information, see the Remarks section of WebHeaderCollection. For a good general discussion of usage, see HTTP Communication and Security with Silverlight.

Encryption is the process of making the data request and data response as difficult to intercept and understand as possible. If you send a username and password to a web service to authenticate yourself as a user of an application (or as an application acting on behalf of a user), that request almost certainly goes through many routers on the way to or from the web service. To prevent either the exposure of your identity credentials (and therefore any potentially sensitive data), your application and the web service need to collaborate to render it largely unreadable except to the two. The standard mechanism to do this is to connect with an HTTPS connection, which is an HTTP connection over a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection.

In most cases, you do not have to do anything to enable this for your Windows Phone application with the exception of using an address that begins with the https:// protocol scheme. Windows Phone then examines the certificate that is returned by the web service, and if the certificate is from one of the trusted authorities listed in SSL Root Certificates for Windows Phone, the Windows Phone Application Platform then uses the certificate in conjunction with the web service to encrypt all further communication, including the exchange of the authentication credentials as described previously.

Although you can install trusted certificates on the Windows Phone, in the current release, the Windows Phone Application Platform does not expose those certificates’ values to applications. As a result, in the current release, you cannot implement mutual authentication scenarios – scenarios in which the client sends its own certificates to the web service in addition to receiving one -- using certificates installed in the root store.

Applications often ask users to provide a username and password that are used as credentials to authenticate the user with a web service or website, yet if they do so each time the application is run, users can become annoyed.

We strongly recommend that your application prompt for usernames and passwords each time your application needs them from the user; if you attempt to save the credentials on the phone. you risk exposure of those credentials to a malicious application if the Windows Phone is lost or stolen. Use the ProtectedData class and the associated cryptography classes to encrypt and store sensitive information in your application. For more information, see How to: Encrypt Data in a Windows Phone Application.