OAuth Recommendations for Single-page Apps
The OAuth 2.0 Authorization Framework contains considerable power and flexibility in how it can be integrated into applications. Since its first release more than five years ago, the framework has been greatly extended with new capabilities both in the core specification and in industry-contributed specifications.
Because of OAuth’s versatility, developers and administrators often have many choices in how to best utilize the framework to meet their needs. As a result, it has become increasingly common for experts and solution providers to offer structured guidance to help simplify configuration and deployment, as well as to avoid potential future interoperability and security issues.
As part of providing that guidance, Ping Identity is pleased to share recommendations to our customers for integrating OAuth and OpenID Connect with single-page applications (SPAs).
Single-page applications and native applications have significant overlap in terms of behavior. The IETF recently published a BCP (Best Current Practices) on OAuth and OpenID Connect integration with native applications (such as user-installed apps on a mobile device), nicknamed “AppAuth.” The SPA recommendations to our customers build upon these AppAuth recommendations. Consequently, the SPA recommendations align single-page applications more closely with native apps with regards to configuration, integration and administration.
It is our hope that these SPA recommendations will eventually lead to similar best practices being established across the industry.
OAuth 2 for Single-page Apps: Recommended Practices
It has been our experience that SPAs often use a homegrown single sign-on (SSO) solution or lightly modified examples, which often leave them open to possible security issues. We have put together suggested options for utilizing OAuth and OpenID Connect standards, as well as environmental considerations and technologies recommended to harden browser-based applications against common threats.
These recommendations include:
- During SPA deployment, plan for OAuth support distributed within the application logic, such as via a JavaScript library. For a single-page app, requests are typically sent via a mechanism such as XMLHttpRequest (XHR) or Fetch. While server state such as cookies could be used to authorize these interactions as well, supporting even typical authentication features like session timeouts will often result in the eventual creation of complex, custom solutions. Instead, we recommend support distributed within the application logic, which allows for greater control of authorization by the application.
- Apply AppAuth guidelines when converting an SPA into a native app by use of frameworks such as Cordova, Electron or React Native. Invariably, these frameworks provide a more sophisticated and persistent user experience by offering integration with the system software and device hardware not normally provided by a browser. In these cases, the application is being deployed as a native application, and the guidelines of AppAuth should be applied.
- Do not rely on client authentication via statically provided credentials. Similar to native apps, an SPA with native OAuth support is a public client. This means that since the application is distributed, it cannot contain provisioned secrets; any embedded credentials used to authenticate the application to the authorization server will be available for potentially malicious parties to extract and use. Whether there is a password or not, other parties will be able to attempt to impersonate your SPA. For this reason, it is not recommended that an authorization server rely on client authentication via statically provided credentials.
Additional OAuth 2 Recommendations
The above is just a brief look at some of the many recommendations we’ve put together for securing SPAs. We have also published an example application using the Angular 6 framework that follows these recommendations, and we intend to publish additional examples of integration using other frameworks in the future, based on customer feedback and interest.
To get the full set of Ping Identity’s recommendations on how to protect single-page apps with OAuth 2.0, download the OAuth white paper.