Adding BankID Login to an App
By CodexierPublished 6 min read
In Sweden, an app that asks for a username and password feels foreign. Users expect to tap a button, approve in the BankID app and be in. Adding BankID is not difficult technically, but it involves a contract, a choice of provider and some security decisions that are easier to get right at the start. This guide covers the flows, the two ways to get access, session handling and what to offer users who do not have BankID.
Why BankID matters in Sweden
BankID is used by nearly every adult in Sweden for banking, public services and e-signing, so the mental model is already there. For an app, that means no onboarding friction from passwords, no reset flows, and a user record tied to a verified identity, which matters for healthcare, finance, housing, membership and anything where two people must not share an account. It also enables e-signatures with legal weight. The cost is a contract and a small fee per identification, trivial compared with the support costs of passwords.
Same-device and QR flows
When the user has BankID on the same phone as your app, your app starts an authentication order with the BankID service, receives a start token, opens the BankID app with it, and the user approves with a code, fingerprint or face. BankID returns the user to your app, which collects the result from the service. When BankID is on a different device, such as the user's phone while they use your app on a tablet or the web, your app shows a QR code that changes every second; the user scans it with BankID and approves there. Both flows end the same way: your backend receives a signed completion with the user's name and personal identity number.
| Flow | When it applies | What your app must do |
|---|---|---|
| Same device | BankID app installed on the phone running your app | Launch BankID with the start token; handle the return to your app |
| Other device (QR) | User authenticates on a second device | Render the animated QR code and poll for completion |
| Both | Always | Start and collect orders from your backend, never from the app directly |
Direct agreement or identity provider
You cannot call the BankID service without a relying-party agreement, and those are issued through the banks. A direct agreement gives you your own certificate and the lowest per-use cost, but it involves bank onboarding, certificate management and building the integration yourself, and the test environment must be set up separately. An identity broker holds the agreement for you and exposes a standard login API, often with Freja eID, Norwegian and Danish e-IDs and e-signing in the same package. Brokers cost more per login but get you live in days rather than weeks and handle certificate renewals and protocol changes. For a first app, a broker is almost always the right start; a direct agreement becomes worth it at high volume.
- Direct agreement: lowest unit cost, more setup, you own the certificate and its renewal.
- Broker: standard OpenID Connect login, fast onboarding, other e-IDs included, higher unit cost.
- Either way, the app never holds the certificate; all BankID calls go through your backend.
- Plan for the test environment early; reviewers at the app stores will need a working login.
Security and session handling
BankID proves who the user is at one moment; your app decides how long to trust that. Issue a session token from your backend after a successful identification, store it in the platform's secure storage, and set a lifetime that matches the sensitivity of the data: days for a membership app, minutes for anything financial, with re-authentication for sensitive actions. Verify the completion data on the server, including that the order your backend started is the one that completed. Treat the personal identity number as sensitive personal data under GDPR: use it only if you need a unique identity, and consider storing a hashed or internal identifier instead.
Fallback for users without BankID
Some users cannot use BankID: newly arrived residents, minors without their own, people whose bank has revoked it, and anyone in the gap while replacing a phone. For a consumer app, offer an alternative such as email with a one-time code, or Freja eID if a broker provides it, and make the alternative visible without being the default. For a B2B app, the customer's administrator can invite users by email, which sidesteps the problem. Decide up front which features truly require verified identity and gate only those. BankID integration is a standard component of a cross-platform MVP app build; the price is on our pricing page.
When you do not need this: an app for your own staff, where accounts are created by an administrator, is fine with email and a code or the company's existing Microsoft or Google login. A content app with no personal data does not need verified identity at all. If your users are outside Sweden, BankID is irrelevant and you need the local equivalent or a plain login. Not sure which applies? Book a short call and describe who your users are.
Frequently asked questions
How long does it take to get BankID into an app?
With a broker, the integration is usually a matter of days once the agreement is signed. A direct agreement through a bank takes longer, often several weeks, before the first test login works.
Does BankID work for users under 18?
Banks issue BankID to minors on varying terms, so many teenagers have one but some do not. If your users include young people, plan a fallback login and check what identity level your service actually needs.
Can I use BankID for signing documents in the app too?
Yes. The same integration supports signing, where the user sees the text they are approving in the BankID app. Most brokers expose it as a separate call. Signed documents have legal weight in Sweden and can replace paper contracts.
Planning an app that needs verified users?
Fifteen minutes with an engineer: you describe your users and what they do in the app, we tell you whether BankID is needed, broker or direct, and what fallback to build.
Book a free 15-minute call