Skip to end of metadata
Go to start of metadata


This document proposes a strategy to support authenticated access to UW campus services from within an application running on a mobile platform.


The analysis and recommendations that follow are made in the context of a UW affiliated user interacting with a purpose-built application running on a mobile device accessing a campus resource over the HTTP protocol.  Authentication requirements within the context of mobile-optimized, web-based applications (i.e., applications running within the mobile device's web browser) are suitably addressed by the current UW NetID Weblogin Service.


Mobile device (i.e., smartphone) usage is ever increasing along multiple dimensions.  The numbers of users shows no sign of slowing. Device selection is growing - iPhone, Android, BlackBerry, webOS, Windows Mobile among the more popular. The variety and richness among the applications that devices support is growing. Rich connectivity, increasing bandwidth and the growth of data sources and services all combine to increase user expectations. This growth, ubiquity and convenience has lead to a clear demand for access to personalized, private content.

To accomodate the growth of compelling content in mobile applications such as m.UW as well as to foster the serendipidous developement that can lead to groundbreaking applications, we analyze below available technologies that allow authenticated access to personal resources within UW-IT and the campus community.

Authenticated access to hosts, web pages, other resources within the UW today is based on a variety of technologies depending, typically, on capabilities and needs of the resource requiring authentication.  Beyond direct host-based credential management, distributed approaches typically take the form of credential distribution via LDAP and a centralized authentication service based on Kerberos.  Typically, authentication to protected web-site content is provided via UW Pubcookie Single Sign On implementation which, effectively extends the central authentication service to the web.  Authentication to protected web-based services is currently often implemented via X.509 client certificates.

Requirements and Goals

To be considered a successful strategy, an authenticated mobile application arising from it will have the following characteristics:

  • It provides authenticated access without revealing user credentials to third party applications.
  • it prevents stored user credentials within the mobile applications.
  • It minimizes the number of credential prompts per device, per application on the device and per instance of the application on the device, thus:
    • Providing for the best user experience
    • Reducing the risk of conditioning users to enter credentials without consideration
  • It provides a consistent, recognizable user experience for credential input to minimize the effectiveness of phishing and spoofing attacks
  • It will have authorization scoped only to the requested service

Similarly, considering the growth and direction of the mobile application space, an effective strategy needs to:

  • Facilitate and encourage best security practices
  • Minimize resource access friction
    • For mobile developers, it must be simple to implement.
    • For resource providers, it must be easy to implement with readily available tools.
  • Embrace open standards to encourage wide deployment and thus serendipitous development.
  • Be as vendor neutral as possible to maximize platform choice
  • Minimize implementation cost to UW-IT
    • By leveraging existing proven, mature authentication infrastructure where possible
    • Minimizing the amount of development, integrations and implementation work
  • Minimize time to market
  • Do nothing to preclude the compelling use cases presented in the appendix

Current Landscape

Mobile application authentication, at the time of this writing, is not exactly a well established art - there is little in the way of general thought or broad consensus. Nearly all recognize the need, but few have committed much thought, and even fewer have implemented anything.

Below we capture what has been done, what some are thinking and some promising technologies to support mobile authentication.

X.509 Certificates

What appears to be the earliest and possibly most expedient approach was implemented via personal X.509 certificates. This solution requires the installation of personal identity certificates on the mobile device and using the mobile devices facilities for secure communication to identify the person that has access to the device to the service.

This method has been used to authenticate desktop applications on some campuses, most notably MIT. MIT has investigated this solution for use in the mobile context, but is currently not using it.

This solution appears to lack convenient, broad device support as we are only aware of support in Windows Mobile and iPhone.


Personal certificate advantages include straightforward and seamless authentication experience once the device is configured and the infrastructure is in place.


The primary disadvantage is the general lack of a personal certificate infrastructure on the UW campus. In addition, it is unclear how broad and convenient support is across popular devices.


Kerberos is an Internet standard designed to provide authentication and secure network communication.  It can support a seamless, integrated authentication environment where the user identity established at login is leveraged to automate the user's authentication to network resources.


Kerberos main advantages are that it's mature, stable and open and widely adopted.  UW-IT currently provides a central kerberos infrastructure and has experience adapting services to support this technology.


The main disadvantage is lack of support among mobile device vendors.  While BlackBerry is reported to have plans for kerberos, it is not clear other vendors have similar plans for adoption. It is possible to build kerberos client functionality directly into the mobile application, however kerberos tickets cannot be shared among applications which will require each authenticating application to prompt for user credentials. Lastly, we are not aware of any web-based services supporting kerberos of authentication.

Adapted Web-SSO

The adapted web-SSO approach extends an existing Web-oriented Single Sign On infrastructure onto the mobile platform. The ideas is that the mobile application is built with some knowledge of the campus web-SSO technology and leverages that knowledge to acquire the necessary access tokens that permit authenticated access.

Two implementation strategies have been identified that take this approach.

In-Application Web-SSO Authentication

The first has been suggested in conversations with other institutions and is the solution proposed by BlackBoard for m.UW. The approach employs a programming feature of some devices that allows an application to seamlessly display web content within its context. Specifically, a client requiring authentication will issue a request to the campus web-SSO service from a browser instance, or user-agent, running within the application itself. Once the user has authenticated and the necessary tokens are acquired, the application then uses those tokens to access the required service.

The iPhone and Android platforms are known to support this feature, but it is unclear to what extent others such as BlackBerry, Windows Mobile and webOS offer it.


The obvious advantage to this approach is leveraging UW-IT's existing web-SSO infrastructure to minimize cost and time. Similarly, it offers a reasonably low bar for client adoption since the in-application browser does most of the work. The other advantage is that it provides a relatively seamless, familiar user credential prompt experience.


The disadvantages range from user inconvenience to increased risk. Since, commonly, no state can be conveniently shared between applications, the user will be required to enter credentials for each authenticating application. While this conditions users to enter credentials frequently, at least UW-IT can control the prompting interface such that a strategy similar to SiteKey could be used to mitigate the likelihood of phishing success. Unfortunately, since the user-agent instance runs within the application context, it is unclear that the user's credentials would be entirely safe from third party application access. Generally, this is not a well regarded approach.

Further disadvantages include likely authentication token caching and expiration policy conflicting with application lifecycles. It's quite possible, depending on device constraints, that users would have to enter credentials more than once per "session". Similarly it provides for no uniform user experience with regard to destroying authentication tokens.

Lastly, this approach requires some amount of web-SSO technology-specific code in each client application, and it isn't clear how pervasive support is across platform vendors for in-application browser instances.

Dedicated Web-SSO Application

The second approach was outlined, implemented, and will soon to be deployed by the University of Michigan, <>. It was similarly suggested as a solution by MIT. The solution rests on a programming feature of some devices that permits at least a modest amount of interprocess communication.

Rather than leaving it to each application to communicate directly with the established web-SSO infrastructure, this approach involves installing a dedicated web-SSO application on the device that manages authentication resources on behalf of other applications on the device.

The web-SSO application alone is responsible for prompting the user for credentials as well as managing the authentication token lifetimes. A client requiring authentication issues a request for the necessary authorization token to the web-SSO application via the device's supported interprocess communication method. The web-SSO application performs any necessary actions and responds to the application with the requested token.  The graphic below illustrates the interaction between the data-consuming application, web-SSO application and resource.

iPhones and Android-based devices are known to support this approach, but it is unclear at this time whether other platforms will as well.


Besides leveraging existing infrastructure as stated above, there are several notable advantages to this approach. First, one application managing web-SSO interaction minimizes the number of credential prompts a user will encounter. Second, the single, familiar prompt discourages users from entering credentials in less secure contexts. Lastly, the web-SSO managing application allows for a unified "logout" functionality allowing the user to revoke access if desired.

In addition, in terms of minimizing cost and time to market, this approach has the advantage that there is the possibility the UW could adapt UMich code to function within the UW infrastructure.


This approach, as well, shares the disadvantage in that it requires some amount of web-SSO technology-specific code in client applications. Similarly, it has the breadth of platform support limitation shared by the in-application strategy.

Further, in terms of user experience, the strategy does exhibit "app bounce" as focus is transferred from client application to web-SSO application and back as the required authentication token is acquired.


OAuth is an open authentication/authorization protocol designed to allow users to share private resources similar to the way a "valet key" works. Of particular interest is the ability to support three legged authentication allowing a user full control over third party access to their data without sharing any credentials. See <>.

Briefly, OAuth clients gain access to resources on behalf of a user by requesting a token from an authorization server. To acquire a token, the client redirects the user to an authentication server, much like pubcookie clients are redirected to the login server, where the user enters their credentials and grants access. Upon granting access the server returns the necessary token to the client.

Unlike pubcookie, the key feature of OAuth tokens are that they can have an arbitrary lifetime defined by the user, can optionally grant read-only access and can be revoked at any time.

Mobile client implementations face similar credential acquisition issues described in the web-SSO strategies above. However, OAuth provides for options beyond in-application user-agents or a dedicated OAuth application; clients can register with the authorization server leaving it to the user to grant access externally or users can acquire an access token prior to initializing the client application.

The client platforms supported depend on the method the application uses to acquire the authorization token. Client implementors may choose strategies similar to the web-SSO adaptation, or one of there other supported approaches, so the widest ranges of clients is possible.

Services that implement OAuth include the likes of Google, Yahoo, Facebook, Flickr and Twitter.


The primary advantages of OAuth are twofold. First, as an open standard, any client can leverage existing code to authenticates to any compliant service. Second, it gives the user fine grained control of the information they share with what is likely to be a broad range of clients. These advantages combine to increased the likelihood of serendipitous development that in turn leads to compelling applications - such as, for example, a Google calendar populated with a class schedule.

Additionally, this approach may offer the opportunity, should the UW choose to base future applications on the MIT Mobile framework, to contribute broadly useful work back to the project.


OAuth is not without its disadvantages. First, the standard is in a state of flux. Most current deployments are based on rfc5849, but work is underway in an IETF working group on the successor draft-ietf-oauth-v2-08.

Further, similar to the SSO integration strategies described above, this approach can lead to less seamless methods for acquiring access tokens which range from completely out of band to a dedicated authorization application similar to the SSO-application strategy.

In terms of cost and time to market, a solution based on OAuth technology is likely the most costly as there is currently no OAuth infrastructure within UW-IT.

Other Technologies Considered

HTTP Basic Authentication was considered, but fails the user credential divulgence test.

OpenID was looked at, but provides little advantage over, and is somewhat redundant to, UW Pubcookie.


Based on the requirements and goals stated, allowing for time and cost constraints, and considering the maturity and adoption of the authentication technologies presented above, it is the opinion of this group that UW-IT pursue a mobile device authentication strategy based on the dedicated web-SSO application approach.

The X.509 Certificate approach is a non starter due to the lack of campus infrastructure.

The Kerberos approach falls short due to limited mobile device adoption.

The in-application web-SSO approach requires the user to enter their credentials for each application.  Worse, there are no guarantees the application cannot access those credentials, and it conditions users to to enter credentials whenever they're requested.

The OAuth approach is clearly the most flexible in the long run, and would be the likely choice were cost and time weighted less as requirements.

The dedicated web-SSO application approach provides a single, official context for credential collection, and device-wide management of authentication tokens.  In terms of cost and time, it is likely UW-IT will be able to build on knowledge acquired by peer institutions, if not adapt actual code that is already in use at those institutions.

APPENDIX A.  Use Cases


In developing a mobile authentication solution and strategy it is critical that key use cases are developed understood and prioritized. The goal of this document is to create a prioritized list of use cases that explores some of the most important use cases for mobile authentication that we know today.

Use cases

Use case #1: Class schedule and location
Priority: High

Joe Student has just finished meeting with a professor in the physics building. His phone buzzes he looks down and realizes he has to be in his chem E class in 10 minutes. He clicks on the class and chooses, give me the fastest route to my class. On the phone a map appears along with directions to his class.

Use case #2: Resource finding and reservation
Priority: High

Diego’s Technical Communications project group meets at By George to get started on their class project. The environment is too loud for them to hear each other w/o yelling, so they decide to try to find a group study room.  Sandra suggests that they get a room with a large monitor that they can all sit around and edit the project report as a group. Diego pulls out his smart phone, opens the UW Resource Finder app and searches for available “study rooms” that can seat 6+ people and has a large monitor. The search returns a list of available rooms that match the search criteria, sorted by nearest to furthest away.  There is also a map, showing where these rooms are on campus.  Since Diego is authenticated as a Business School student, he also sees the Business School study rooms that are specifically available to him.  He clicks on a room, sets the times that he wants to reserve the room for and clicks “Submit Reservation”. The group relocates to their new room. When they are finished with their work, Diego finds the nearest available printer and prints their project paper for submission. He picks the paper up on his way to his class.

Use case #3: Course work info including assignments, deadlines, grades, and office hours
Priority: High

It is Monday and Amy is at lunch with some friends when her phone buzzes. She reads the message that her Technical Communications teacher has canceled class due to illness, but wants to make sure that they finish their readings for discussion on Wednesday.  Amy wants to make sure that she has all the readings that her instructor is referring to, so opens up her UW Class app.  She sees a listing of her classes and quickly finds the reading assignment for her TC class.  She is relieved to find that she has all the readings she needs at home.  She quickly scans the Upcoming Dates for her classes and sees the 2 Collect It assignments she is working on are both due at 5pm on Friday. She also sees that a new assignment has been posted for her History class, for which she will need to meet with her TA to discuss paper topics. She finds her TA’s office hour schedule and schedules a quick 1-hr meeting for later in the day. As she is doing this, she sees an alert show up next to her ENGL 201 class. Her grade on last week’s assignment is was a 74.  She decides to cut lunch short in order to get started on her English paper.

Use case #4: Mobile worker
Priority: High

Case a

Jill Smith works for a University IT organization. She spends much of her day away from her desk troubleshooting network and computer problems and installing equipment. As she is returning from lunch she pulls out her mobile to access Request Tracker (RT) to see which items need to be resolved next. While in RT, she updates the status on an outstanding item and resolves two questions that have been waiting for her input before leaving to her next location. Once at the new location she finds a problem with a network switch. Using the camera on the mobile she takes a picture of the offending device and attaches it to the ticket in RT. 

Case b

Jack is the manager of a technical team who is often away from his desk in meetings. His teams use Request Tracker, the UW Wiki and Google Docs to complete their work. Jack has a few minutes between meeting to catch up on email. He takes out his mobile to check his mail and finds an note from Request Tracker alerting him to a problem with a project. Clicking the link in the note and entering his credentials, he views the RT ticket history to understand the problem. Jack recalls that there is information on another project that may help and opens the UW Wiki page for that project. Finding the relevant information he copies the link to that page and updates RT with the relevant information before sending it back to the appropriate team. 

Use case #5: Researcher workflow, deadlines and basic info

Priority: High

Research workflow use cases

case A: A principal investigator is in between lectures at a conference, and wants to see the status of his grant submission.  He opens up his mobile app and checks to see that his grant has been validated by the sponsor.

case B: A grant preparer has just finished up a meeting and would like to see if his Dean has approved his PI’s grant application since the deadline date is tomorrow. He uses the mobile app to check status and verifies that his Dean has not approved it yet.

Deadlines and basic info

case A: A principal investigator is notified via her mobile device that a grant deadline for one of her applications is next week and it is still in composing status.

case B: An approver is having a discussion with a co-worker over lunch and there is some debate on the specifics of fiscal responsibilities.  She uses her mobile device to quickly bring up GIM 2 information and verifies her assumption.

case C: On the bus ride in to work, a preparer scans the research calendar for upcoming sponsor deadlines in the next quarter for her PI.

Use case #6: Enhanced white pages
Priority: High

Case a - Personalized contact experience

Julie is running late for her meeting with professor Johnson. She opens up m.UW, chooses "my contacts" and then clicks on "my professors". A list of her professors comes up and she clicks on professor Johnson. Her phone asks "dial professor johnson now?" and she clicks yes while trying to quickly think o up an excuse for her tardiness.

Case b - Improved privacy controls

Bill has been constantly harassed by an individual outside the UW. He decides to change his number and remove himself from public listings. He still wants his coworkers to be able to contact him so he sets his preferences to allow only UW Employees to see his contact information. UW employees are able to authn in m.UW and see Bill's contact information while all others are unable to see Bill.

Use case #7: Mobile data collection
Priority: High

Research assistant Ronda travels the northwest to periodically survey participants in a study.  She enters their confidential responses into an app on her smartphone that gathers the results and makes them immediately available for analysis at her lab on campus.

Use case #8: Tuition reminder and payment
Priority: Low

Ima S Lacker feels a buzz in his pocket. He pulls out his phone sees the message:
Payment Reminder: UW Spring Quarter Tuition is due by Friday, April 4
He clicks on m.UW and chooses Tuition Payment options. He sees the options pay now, pay on web and send to reminder to parents. He chooses "pay now" and m.UW asks him to confirm the tuition total. He confirms and is sent a confirmation text and email.

Use case #9: Creating Connections for Prof
Priority: Low

Prof. Johnson is walking through the quad. A student, Ralph Smith, passing by him smiles and says, "hey Dr. Johnson." Prof. Johnson smiles and replies "hey." Prof. Johnson, thinks to himself, what is that students name? I know he's in my math 307 class. He pulls out his phone, opens up m.UW and thumbs through photos of the students in his math 307 class until he finds a picture of Ralph. He selects the picture and finds Ralph's name, email, and phone number.

  • No labels