Recommendations for designing solutions in the OAuth 2.0 framework

OAuth 2.0 / OpenID Connect must be seen as a framework for designing solutions to delegate access. The framework allows for a lot of flexibility.

For any solution designed in this framework, be aware of the following:

1. The fact that a solution follows the OAuth 2.0 specification does not imply that the solution is secure. To obtain secure solutions, one must specifically design them for the security requirements at hand and ensure their security using appropriate measures, such as, but not limited to: security consulting, internal and external security reviews in the design, implementation and integration phase and penetration tests.
2. The framework has been designed to allow access delegation. However, OAuth 2.0 is often employed to implement single-sign-on (i.e. to achieve authentication goals). Historically, this has lead to many vulnerable authentication solutions. We would like to stress our recommendation (1.) especially in this case.

Over the past few years, the use of OAuth 2.0 / OpenID Connect for mobile applications has increased drastically. This lead to a variety of vulnerable implementations.

In particular, the following points are important:

1. The OAuth 2.0 framework heavily relies on browser redirects. If this mechanism is omitted or replaced by other mechanisms in mobile applications, the solutions are prone to be insecure.
2. Public native app clients should implement the Proof Key for Code Exchange (PKCE) extension to OAuth. Airlock IAM as authorization servers should be configured to use PKCE support to secure the authorization process.
3. OAuth 2.0 authorization requests from native apps should only be made through external user-agents i.e. the user's browser.
4. Using the Implicit Grant has lead to insecure solutions. This grant type is not recommended for mobile applications.
5. The general points discussed in the previous subsection.