Upgrade Your App2App Logins to BankID v6

Key Takeaways

  • App2App authentication externalizes login security to a specialist third party (like BankID), providing strong MFA and a smooth user experience without building it in-house.

  • OAuth/OpenID Connect govern token issuance before and after login — App2App defines the authentication method itself, filling the gap between the two.

  • BankID integrations should run through the authorization server, not custom app code, to keep token issuance correct and centralize complexity across apps.

  • BankID Secure Start becomes mandatory May 1, 2024 — requiring an upgrade to v6 of the Relying Party API. Curity Identity Server v8.5+ supports this natively.

  • Beyond login, App2App enables advanced flows like CIBA (agent-initiated remote authentication) and PSD2-compliant Open Banking consent with digitally signed, non-repudiable transactions.

  • Because a third party continually evolves its security, ongoing upgrades to both the app and backend integration are required — this isn't a one-time setup.

On this page

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.

BankID Logins

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:

bankid (1)

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.

curity-bank-id-app2app-2blog

Conclusion

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.

Related resources

Frequently Asked Questions

Is App2App authentication only relevant for BankID?

No — BankID is one prominent example, but the App2App pattern applies to any national or bank-grade identity scheme that uses a dedicated authenticator app. Similar models exist elsewhere, such as MitID in Denmark, itsme in Belgium, and various bank-issued authenticator apps used across Europe for strong customer authentication under PSD2.

What happens if a user doesn't have the BankID app installed?

Most organizations offering BankID as a login option provide a fallback authentication method (such as username/password with a second factor, or another supported eID scheme) so users without the app aren't locked out. The authorization server typically manages which methods are offered based on configuration.

Does App2App work if the user only has one device?

Yes — same-device flows use a deep link to switch between the requesting app and the authenticator app on that single device, rather than requiring a second device. Cross-device flows (using a QR code) are the alternative when a user wants to authenticate from a different device than the one they're using.

How does App2App compare to SMS-based one-time passcodes (OTP)?

App2App is generally considered more secure than SMS OTP, since SMS is vulnerable to SIM-swapping and interception. App2App relies on cryptographic keys bound to the device and app, rather than a code sent over an insecure channel.