Share via


Authentication Options for Mobile Devices

This section on designing secure applications describes the additional complexities of authenticating mobile devices.

The following topics are also discussed in this section:

  • Windows Authentication
  • Passport Authentication
  • Forms Authentication
  • Authentication on devices that do not support cookies

Windows Authentication

Internet Information Services (IIS), in conjunction with ASP.NET, provides the functionality for negotiating Microsoft Windows-based authentication with the client. In an unsecured application, i.e. one using Anonymous authentication, the specific identity of the requesting user is never considered. Instead, the request is executed by using default accounts that were set up during the IIS installation. Using Internet Services Manager, you can choose from the available Windows authentication models, including Basic, Digest, and Integrated Windows. You can configure these using the Internet Services Manager snap-in for Microsoft Management Console. IIS negotiates the credentials based on which authentication methods the browser supports, and which authentication methods are enabled for the application.

Basic Authentication

Many mobile devices on the market today support only the Basic form of authentication. Basic authentication is the most widely supported credential exchange mechanism but, by itself, is not secure because there is no encryption.

Caution   Using Basic authentication transmits user names and passwords in clear text. If you do not use Secure Sockets Layer protocol (SSL) to protect the application, the data is subject to outside observation. Using HTTPS is strongly recommended for those cases.

Passport Authentication

The ASP.NET does not support using Passport in conjunction with mobile devices. For more information on Passport authentication in ASP.NET, see The Passport Authentication Provider.

Forms Authentication

Forms authentication is a part of the .NET Framework architecture that provides for authenticating users without utilizing the IIS authentication primitives. The general sequence of events is:

  1. Client requests a page.
  2. Browser is redirected to the logon form specified in the configuration if the user is not already authenticated.
  3. Client provides credentials in a form posted back to the server.
  4. Server validates the credentials, writes the client cookie, and redirects back to the original page.
  5. Authentication cookie is checked and the original page is served.

Step 4 creates a problem for some devices that do not support cookies. The MobileFormsAuthentication.RedirectFromLogin page writes the authentication information into the query string. To keep the user from being redirected to the logon page for every request, the authentication information can be presented in each request as part of the query string. ASP.NET provides a method for carrying data such as this in the query string for relative URLs.

For an example of how to perform forms authentication, refer to the MobileFormsAuthentication Class description.

Caution   Form authentication sends the username and password in clear text by default. It is therefore recommended that you use HTTPS for this and other sensitive information, and specify <form requireSSL=true /> in the Web.config file. If a device does not support SSL directly or through the gateway and it tries to access a page that requires SSL, an error message will be displayed to the user.

Authentication on Devices that do not Support Cookies

Browser authentication models typically use cookies for tracking the authentication of the user. Many mobile devices do not support cookies and are therefore unable to authenticate by this means.

Providing Basic authentication primitives for the widest array of devices possible adds value for the developer targeting mobile devices.

Cookieless authentication requires that an authentication ticket be accessed in another location. In forms authentication, if the cookie is not present, the ASP.NET authentication module checks for it in the query string. You implement this by including the session ID in the query string. This requires rewriting all links on a page to include the authentication ticket conditionally based on these factors:

  • Is the application configured to persist cookieless data? This is determined by the setting of the CookielessDataDictionary property of the IPageAdapter interface.

  • Does this device require cookieless authentication?

    Note   You cannot configure an individual device for cookieless authentication.

The CookielessDataDictionaryType attribute in the <mobileControls> section must be set in order for authentication to work properly on cookieless devices, as well as devices that have SupportsCookieWithRedirect set to false. By default, the CookielessDataDictionaryType attribute is set to System.Web.Mobile.CookielessData in the machine.config file. To override this behavior for a single application, you must set the CookielessDataDictionaryType attribute to an empty string ("").

Be aware that some devices and browsers currently require fully qualified URLs in response to an HTTP redirect. Set useFullyQualifiedRedirectUrl=true in the System.Web section of either the Machine.config file or Web.config file (at the application level). For more details, see Redirecting to a Mobile Web Application.

Additional security recommendations can be found in the Securing Applications and the ASP.NET Web Application Security sections of the .NET Framework SDK documentation.

See Also

Designing Secure Mobile Applications