Skip to main content
sajn Login lets your users sign in to your product with Swedish BankID. You get a verified identity back; sajn holds the BankID agreement, operates the certificate, and runs the login screen. It is a standalone product. You do not need a BankID agreement of your own, you do not need to handle certificates, and you do not need to use sajn for e-signing.

Standard OpenID Connect

Authorization Code flow with PKCE. Any OIDC library works — NextAuth, Auth0, Keycloak, passport, ASP.NET. No sajn SDK required.

Or a plain REST API

Two calls if you would rather not run an OIDC client. Ideal for mobile apps that open the login page in an in-app browser.

Your name in the BankID app

With your own hosted certificate the user sees “Legitimera dig hos Acme AB” — not sajn.

Nothing to operate

Certificate lifecycle, QR rotation, accessibility timers and BankID’s API changes are ours.

How it works

Step 6 happens from your server, authenticated with your client secret. That is what makes the result trustworthy: the browser only ever carries a single-use code, never an identity.

Two ways to integrate

OpenID Connect

The default. Point any OIDC library at our discovery document and you are done.

Session API

POST to start a login, GET to read the result. No OIDC library needed.
Both use the same hosted login page, the same BankID engine and the same claims. They differ only in how a login starts and how you collect the result. You can use both at once — one client per application.
Not sure which? If your application already has a login system that speaks OIDC, use OIDC. If you are building a mobile app and would rather make two HTTP calls than configure an OIDC client, use the Session API.

Core concepts

One per application. A client owns its redirect URIs, the data it may request, the language its login page renders in, and its credentials.Clients are reviewed by sajn before they can authenticate anyone. You create one as a draft, submit it, and we approve it. Changing a redirect URI or the requested data later sends it back for review — an approval describes a specific configuration, not just a name.
The stable, pseudonymous identifier for a person within your organization.The same individual signing in to any of your applications always yields the same sub. It cannot be correlated with their identifier at any other sajn customer, and the personnummer cannot be derived from it. Store sub as your user key — not the personnummer.
The BankID relying-party certificate a login runs on. It decides the company name shown in the BankID app.By default that is sajn. Order your own through us and your users see your company name instead — that is the reseller part of the product, arranged with our team rather than self-served.
A certificate is either a test or a production certificate, and a client inherits that.Test clients talk to BankID’s test environment and only accept test BankIDs from demo.bankid.com — they can never authenticate a real person. See Testing.

What you get back

Request only what you need — every scope beyond openid is reviewed before your client is approved, and nin in particular needs a reason. Full detail: Scopes and claims.

How it differs from sajn ID

sajn Login and sajn ID both use BankID, but solve different problems. Rule of thumb: if you would call it login or sign-in, it is sajn Login. If you would call it KYC or onboarding, it is sajn ID.

Getting access

sajn Login is enabled per organization by our team, and each client is reviewed before it goes live.
1

Talk to us

Contact sajn to enable sajn Login for your organization. If you want your own company name in the BankID app, this is where the reseller sub-agreement and certificate ordering start.
2

Create a client

In the sajn dashboard: Inställningar → Utvecklare → sajn Login. Set the name your users will see, the redirect URIs, the data you need and the page language.
3

Submit for review

We check the configuration and approve it. Until then the client exists but cannot authenticate anyone.
4

Integrate

Follow the Quickstart.

Pricing

Billed per successful authentication. Failed and abandoned logins are free. Usage is invoiced in arrears alongside your other sajn usage — there is no per-login prepayment, and a login is never refused because of a balance.

Limits worth knowing up front

  • No refresh tokens. A login produces claims at a point in time; your application owns the session afterwards. Re-authenticate by starting a new login.
  • No single sign-on. Every login is a fresh BankID authentication. The phone is the session.
  • No logout endpoint. There is no sajn-side session to end — clear your own.
  • Swedish BankID only today. Other Nordic eIDs are planned; the amr claim is namespaced (BANKID_SE) so adding one will not change the shape of what you receive.

Next steps

Quickstart

A working login in about ten minutes

OpenID Connect reference

Endpoints, parameters and token validation

Session API

The two-call REST alternative

Testing

Test BankID and what differs from production