I confess that most of this '5 Critical REST Services for Mobile Developers' article, focused as it is on the minutia of optimizing REST APIs for mobile applications (like pagination - who knew?) is over my head. But the 5th item in the list, 'Access Control and Security'- that one caught my attention.
The corporate security policy around identity management (aka. authentication) and role-based access to resources must extend to the REST services as well. This means that the users role(s) will determine which resource endpoints are exposed and what operations this role can perform (e.g. READ, INSERT, UPDATE, DELETE). Further, the service must extend down to each table to add a filter to every request (e.g. an employee can only see his/her own records).
OAuth 2.0 is a standardized protocol & framework specifically designed to address the above requirements around authentication & authorization of REST APIs (not just for native application clients of those APIs).
If secured by OAuth, a REST API expects that the API calls made by native applications have attached (as a HTTP header for instance) an 'access token' - this access token previously obtained by the native application from an Authorization Server. The issuance of this access token is typically mediated by the user of the native application - by logging in and (often) giving their consent & authorization for subsequent operations against the API. Because the Authorization Server knows what the native application is, who the user is (and what their roles in the enterprise are), and what authorizations the user themselves granted - the issued access token can logically capture all that identity information (either directly or by enabling a later lookup).
Consequently, when the native application subsequently attaches that access token to its API calls, the API (or some proxy in front of it) can grab the token and extract from it all the identity attributes & associated authorizations. OAuth 2.0 introduces what are called 'scopes' to record what operations (such as the above READ, INSERT, UPDATE, DELETE) are authorized for a given token. If a native application is issued an access token that has the READ scope but not WRITE, UPDATE, or DELETE scope then, were it to attempt to make any changes to the data behind the API, then those calls would fail because they lacked the necessary authorization. Additionally, even if the access token has the READ scope, a separate authorization decision can be made to ensure that, for an HR app as an example, the employee of that app would only be able to view their salary information etc.
While OAuth first arose in the consumer space, its subsequent evolution and standardization under the IETF ensured it can meet enterprise use cases & security requirements. Consequently, OAuth has been deployed across the full continuum - from Facebook to Salesforce. OAuth is also a key building block of the emerging identity stack - OpenID Connect 1.0 profiles and extends OAuth 2.0 to add identity constructs (like Web SSO and identity attribute sharing) and the Native Applications (NAPPS) effort in the OpenID Foundation further profiles & extends OpenID Connect to enable a Single Sign In (SSO) model for native applications.