The mobile app architecture generally differs from a traditional web app architecture in that the mobile app is more distributed. Where a web app is more monolithic in design with complexity suiting a larger screen format with a user present, a web app is generally a more distributed model with a simple client that performs actions against an API on behalf of a user - whether the user may or may not be present.

A mobile application requires a new model of managing authentication and security due to the app architecture and fundamental differences between it and a traditional web app:

  • Traditional web app is monolithic, components can talk to all other components. A mobile app consists of a client communicating to APIs.
  • Web application user is generally always present. Mobile app user may be present or may allow the app to function in the background.
  • Web application allows for a more complex UX due to screen size and device. Mobile app generally simplified UX targeted to a touch device.

Web and mobile architecture

Device capabilities and restrictions also factor into an app design, specifically around security:

  • A mobile device is smaller, therefore easier to lose or be stolen so sensitive data (including stored passwords) needs to be secured on the device or not stored in the first place.
  • The prevalence of BYOD sees enterprise applications alongside personal applications, leading to less secure entry mechanisms to the device (ie no unlock PIN on the device).
  • Ability to work in a disconnected mode (i.e. airplane mode) and attention to user experience results in cached data and credentials.
  • Applications are sandboxed on devices making it difficult to interact with other applications and share credentials and sessions.
  • Mobile frameworks generally have limited functionality exposed through SDKs (i.e. lack of SAML framework for mobile developers)

Although a different architecture, the same fundamental challenges remain: to eliminate passwords and reduce the authentication complexity from the app developer.

As the mobile app architecture generally involves both the app client and a resource or API that the app is communicating with, mobile app security involves securing both sides. Authentication to the app client (for user identification, personalisation, access to stored data etc) and securing of the API calls to the backend services.

Web and mobile authentication

Like web application SSO, eliminating passwords and replacing with a standards-based security token the application developer can offload the authentication complexity from the application to the authentication provider. The results are a flexible token model that the application can use to be assured of the identity of the user authenticating and can use to authorize access to backend APIs (without storing or transferring passwords).

Mobile federated authentication

Authentication to mobile applications is also greatly affected by user experience requirements. Better application user experience may be to authenticate a user natively in the application or via a web view in the application, however would limit the authentication flexibility provided when the user is redirected to the mobile browser for authentication (additional authentication functionality such as certificate authentication and a reusable authentication provider session to facilitate SSO across applications).

The prevailing standards for securing mobile applications are OpenID Connect and OAuth 2.0. These complementary protocols allow and application to authenticate a user, retrieve profile information about that user and identify that user to APIs that it calls on the users behalf.

In the OpenID Connect / OAuth 2.0 flow, a mobile app (client) will redirect the user to the Authorization Server for authentication the result of this will be two tokens returned to the client app, an id_token containing information about the user's authentication event and an access_token which the client can use as authorization to protected APIs.

The client will then validate those tokens and, if valid, consider the user authenticated. If additional profile information is required, the client can call the UserInfo endpoint on the AS to retrieve additional information about the authenticated user.

Mobile OIDC flow