Web service security for Windows Phone 8
[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]
Windows Phone apps have the ability to exchange data with computers all over the world. However, the more valuable the data is – for example, if it is financial data or personal information – the more important it is to make sure that your app requests and receives data using security procedures that reflect the value of that data. This topic describes several different ways to help secure Windows Phone apps when they make calls to web services.
The three major areas that are described are:
Authentication
Encryption of communication
Prompting for usernames and passwords
Security over the internet
Apps that reside on the Internet for the sole purpose of serving data to apps are called web services because they are designed to respond over the Internet to a wide variety of requesting apps on many different platforms: web pages, mobile devices like Windows Phone, desktop computers, and any other device that can support a relatively low level of basic Internet communication protocols. Many requests for public data are quite simple, and require only an HTTP request to obtain data for use on the Windows Phone. For example, many governments publish web services that provide weather forecasts, bus schedules, and other widely available public data to any app that requests it.
Many (if not most) web services, however, exchange information that has some value, either to the web service, the Windows Phone app, or to the person using the app. In these cases, depending upon the value of that information, we strongly recommend that you understand and make decisions about the following security issues so that you can build clients that call web services as securely as is necessary to protect the data that needs to be exchanged.
Establishing an identity
Authentication is the process of asserting to another app 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 app 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.
When using Basic Authentication to establish an identity in Windows Phone, pay attention to non-encrypted data. 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:
.gif "Important note") 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 app could unintentionally expose your app 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 app or of the user of your app 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 for Windows Phone 8.) 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 8.
The HttpWebRequest and WebClient classes restrict access to some HTTP headers; for more information, see the Remarks section of WebHeaderCollection.
Protecting the communication (encryption)
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 app (or as an app 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 the exposure of your identity credentials (and therefore any potentially sensitive data), your app and the web service need to collaborate to render it largely unreadable except to the app and to the web service. 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 app 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 OS 7.1, the Windows Phone app 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 app platform does not expose those certificates’ values to apps. 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.
Prompting for sensitive user information
Apps 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 app is run, users can become annoyed.
We strongly recommend that your app prompt for usernames and passwords each time your app needs them from the user. If you attempt to save the credentials on the phone, you risk exposure of those credentials, such as 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 app. For more information, see How to encrypt data for Windows Phone 8.
Push notifications
If you plan to create a web service to send push notifications to the Microsoft Push Notification Service, we recommend setting up an authenticated web service because communication occurs over an HTTPS interface for better security. Authenticated web services do not have a daily limit on the number of push notifications they can send. Unauthenticated web services, on the other hand, are throttled at a rate of 500 push notifications per subscription per day. For more information, see Setting up an authenticated web service to send push notifications for Windows Phone 8.
See Also
Other Resources
SSL root certificates for Windows Phone OS 7.1