Mobile App High Level Requirements


So far our Code Samples demonstrate a completed SPA and API architecture. Our last post discussed Coding Key Points for our .Net Core API.

We will now start our second theme, focusing on our main company requirements for Native Apps, which covers both of the following:

  • Mobile Apps which run on iOS and Android devices
  • Desktop Apps which are installed on end user PCs

Standard OAuth Flow for Native Apps

If we return to the diagram from the Auth0 web site we can see that we should be using the Authorization Code Flow including PKCE handling:

OAuth 2.0 and Open Id Connect messages are identical for Mobile Apps and Desktop Apps, but there are some other differences which we will cover.

Goal: Pass App Store Approval

Before you can release a new Mobile App to App Stores it will need to undergo a security review from Apple (iOS) and Google (Android). If your Mobile Login handling does not follow guidelines it may be rejected.

Login UX for Native Apps

The recommendation for Mobile Apps is to avoid logins on Web Views and to use newer In App Browsers instead, which overlay the Mobile App’s UI:

Similarly, Desktop Apps are meant to use the System Browser for User Logins, and getting the best UX / technical balance is tricky.

Goal: Best Usability and Password Management

Use of In App Browsers is good from a security viewpoint, and it also provides an integrated user experience, which companies will want for their end users.

Use of passwords on a mobile device is painful due to small keyboards. We want to prevent asking the user to login too often.

On mobile devices we should therefore ensure that browser features such as Remember Password work in the standard way.

Goal: Use Third Party Security Libraries

As for SPAs, we do not want to write any security code ourselves. Instead we will use the respected Google AppAuth libraries, which are recommended by both Apple and Google – and we hope these will help us pass App Approval.

Use of these libraries will also help ensure that we minimize security mistakes, and get us on a good path where we can take library updates for free when new security features are implemented.

UI and API Interaction

Our API Architecture is already complete and will not need to change when we implement mobile and desktop apps in addition to SPAs:

  • Each type of UI will provide access tokens when calling APIs
  • APIs will treat calls from each kind of UI in the same way

Once again we want to use Short Lived Access Tokens (good security), along with Longer Lasting User Sessions (good usability).

Online Examples?

One challenge when implementing OAuth for Native Apps is that currently there are very few third party apps that use the recommended standards:

  • Most desktop apps do not use the System Browser for logins
  • Most mobile apps do not use In App Browsers for logins

This can make it difficult to convince your stakeholders, who may have a Business or UX Focus, that your proposal for logins is right.

Our Mobile Requirements

Here is a summary of this blog’s requirements, which are similar to those for Single Page Applications:

  • Pass Apple and Google Approval so that we can release to App Stores
  • Best Login Usability for End Users
  • Short Lived Access Tokens with Silent Token Renewal
  • Our solution must Pass Security Reviews
  • We want to avoid writing any Complex Security Code

Where Are We?

We know what we want for Mobile Apps but we will demonstrate the OAuth technology for Cross Platform Desktop Apps first:

  • Partly because development and testing is easier on a full screen PC
  • Partly because OAuth for desktop apps has its own challenges

Next Steps