OAuth 2.0 and OpenID Connect are the current mainstream security specifications for protecting data in APIs, and managing user authentication in applications. Organizations use these standards to outsource complexity from application code. After user logins, the application receives an access token with which to call APIs. The organization is in full control of the scopes and claims issued, so that it can protect data in APIs in the correct ways.
To implement authentication, the application runs a code flow, which redirects the user to the authorization server. Users can then authenticate in many ways, depending on the authorization server’s configuration. Application code no longer needs to deal with user credentials or other low level security. Once implemented, this pattern is also easy to scale to many applications, since the complexity is managed centrally, rather than for every application.
Yet OAuth and OpenID Connect only describe behavior before and after authentication. An organization also needs to choose secure authentication methods. App2App authentication is perhaps the most complete way to externalize authentication from the organization. Doing so hands over user authentication to a specialist third party app. This provides an out-of-the-box strong security solution, with multi-factor authentication, a slick user experience and user privacy protections.
A well known example of App2App authentication is BankID in Sweden, where members of the public install the BankID app, either on their mobile device or their desktop. They can then use it to authenticate with any online service that supports BankID.
Users are prompted with a screen where they can either run BankID on the same device or another device. In the former case a deep link is used to invoke the BankID app. In the latter case, BankID is opened and a QR code is scanned to complete the login:
To integrate with BankID, their Relying Party API is used. Although organizations could write frontend and backend code to integrate with BankID, doing so is not recommended when using an OAuth architecture. Instead, this integration should be managed by the authorization server. Following this approach ensures that your app receives OAuth tokens after login, with the correct rights to call your APIs.
BankID Secure Start
Recently, BankID has launched a security initiative called Secure Start, to further strengthen protection against cyber attacks, and to provide stronger guarantees that the person identified to BankID is the same user accessing the organization’s digital services. For same-device logins, an auto-start token must be used, to bind the application instance to a BankID session. For cross-device logins, a more secure animated QR code is used, that is harder to fake. Finally, to protect against malicious clients, a user may no longer start a BankID flow by entering their personal number.
Any organization using BankID should upgrade to these behaviors as soon as possible. Secure Start will become mandatory on May 1, 2024 at the latest. Using Secure Start requires an update to version 6 of the Relying Party API. The preferred way to manage this is to simply use an authorization server with support for BankID’s latest features, such as version 8.5 or later of the Curity Identity Server.
BankID Advanced Use Cases
An App2App architecture can also enable more advanced security use cases, that would be considerably more difficult to implement without an authorization server. One example is a Client Initiated Backchannel Authentication (CIBA) flow, where a customer service operative asks a user to authenticate remotely. In the Curity Identity Server this is done by adding a BankID back channel authenticator.
Another interesting possibility is in Open Banking solutions, where the PSD2 regulation in Europe requires users to consent to runtime payment amounts and recipients. The Curity Identity Server enables OAuth user consent to be customized so that the user is presented with the following type of screen. Such attributes can then be presented in the BankID app and digitally signed, so that the event is recorded in a digitally verifiable and non-repudiable manner.
App2App is a powerful design pattern for externalizing user authentication to an expert third-party, who continually refines their security. As new threats are discovered, users must upgrade their apps and backend API integrations must also be updated. The preferred way to manage the backend integration is to use an authorization server. This reduces work and also enables your APIs to be called with the right access tokens once authentication is complete.
If using BankID, make sure you upgrade to Secure Start and the v6 API as soon as possible. If using the Curity Identity Server, simply upgrade to version 8.5 or higher. For further information, see the Integrating with BankID v6 summary. This provides details on the latest BankID behaviors, along with links to articles on advanced authentication related design patterns.