Authentication With OAuth 2.0 For Trusted Mobile Applications

One of the arguments against OAuth 2.0 is that it ignores mobile applications.  While it’s true that the standard is heavily tailored for 3rd-party clients, it does offer the Resource Owner Password Credentials Grant.  This workflow is a good fit for trusted mobile apps.  For example a user would typically trust the official Facebook and Twitter apps.  The other grant types should be used to authenticate 3rd-party apps, but you don’t need to make the same usability tradeoffs with trusted apps.  Using the resource owner password credentials grant, you can exchange the username and password for a refresh and/or access token, without navigating outside of the application environment to authenticate via an SSL/TLS-protected website.

Some feel that the OAuth 2.0 spec doesn’t do enough to support mobile application authentication, and the wording in the standard doesn’t offer enthusiastic support for the Resource Owner Password Credentials grant, indicating that:

• The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.
• The resource owner password credentials grant type is often used for legacy or migration reasons.
• The authorization server and client SHOULD minimize use of this grant type and utilize other grant types whenever possible.

In spite of this, the Resource Owner Password Credentials Grant type is a good fit for my application.  If you decide to use it, keep the following design guidelines in mind:

• The resource owner credentials should never be stored on the device.  They should be used during the exchange with the authorization server for an access token (and optional refresh token) and then discarded.  The idea behind a refresh token that is used to obtain an access token with a relatively short life (ie. 1 hour) is good, but does it add any additional security?  If the refresh token is compromised the attacker can request unlimited access tokens until the refresh token is revoked.
• All communication should be done over a secure channel (ie. SSL/TLS).
• The client (ie. native application) should be authenticated using both an identifier and a client secret.

The Hybris tech blog provides a nice overview of the OAuth 2.0 Resource Owner Password Credentials grant type, and Riyad Kalla provides a humorous and interesting post about alternatives to OAuth when designing an API.

What design pattern do you follow for native app authentication?  Comment below.