Financial institutions are embracing application programming interfaces (APIs) and open banking to adapt to a rapidly changing consumer landscape. The first volume of the F5 Labs 2020 Application Protection Report finds that over 50% of the cases studied for API breaches and disclosures were authentication and authorization related. The solution to this problem is to correctly use OAuth and OpenID Connect (OIDCOpenID Connect is an identity layer built on top of the OAuth 2.0 protocol, allowing clients to validate the identity of the end user.). The OpenID foundation1 has developed financial-grade APIs (FAPI), a set of specifications to secure APIs in the banking sector. FAPI2 is built on top of OAuth 2.0 and OIDC and addresses security gaps. This article series on Financial APIs discusses these kinds of security controls with this part focusing on OAuth and Proof Key for Code Exchange (PKCE).
OAuth and Challenges with Public Client
OAuth3 is an open standard protocol for authorization that allows for unrelated services to share access without the need to share user credentials. OAuth 2.0 (the current version) provides for an access token used to grant access to APIs. The OAuth specification supports multiple ways to get the access token, known as Grant Types. One of the most widely used grant types is “Authorization Code Flow,”4 used by both web and mobile applications. Authorization Code Flow provides additional security cover because, in its workflow, the application receives an authorization code, which it needs to exchange with the Authorization Server for an Access Token. Figure 1 explains the authorization code grant flow for a native mobile application.