Skip to main content
Scopes decide what your application learns about a user. Every scope beyond openid is reviewed before your client is approved, so ask for what you need and no more.

​
Scopes

openid is implicit — it is always included and cannot be removed. Two claims are present on every authentication regardless of scope:
Changing your client’s scopes returns it to review. An approval covers a specific set of data, not just an application name.

​
The subject (sub)

sub is a pairwise pseudonymous identifier: stable for a person within your organization, and meaningless outside it.

Stable

The same person signing in to any of your applications always gets the same sub, today and in five years.

Un-linkable

Their sub at another sajn customer is a completely different value. The two cannot be correlated, even by us.

Irreversible

The personnummer cannot be derived from it. It is not a hash you can brute-force — the mapping is server-side only.

The right user key

Store sub. It is what identifies a returning user without you holding a national ID number.
If you already identify users by personnummer, you can request nin and match on it once, then store sub going forward. New systems should skip the personnummer entirely.

​
profile

Names come from BankID’s completion data — the name registered to that BankID, not something the user typed. birthdate is YYYY-MM-DD, derived from the personnummer and correct for coordination numbers (samordningsnummer, where the day is offset by 60). You get a date of birth without requesting nin, which is often all an age check needs.

​
nin

The full Swedish personnummer, normalised to 12 digits (no separator).
This is the most sensitive thing sajn Login can give you, and it is reviewed accordingly. Request it only if you have a concrete need — a legal requirement, or an existing system keyed on personnummer. For “who is this returning user”, sub is better and safer.
Notes on handling:
  • nin_type is namespaced against a future where other countries’ identifiers appear. Do not assume the value.
  • It arrives in the id_token, which lands in your logs if you log tokens. The access token is deliberately opaque for the same reason — so the personnummer is never sitting inside a bearer string in a proxy trace.

​
Full example

An id_token payload with all three scopes:

​
One projection, every channel

The same claims appear in the id_token, from /oidc/userinfo, and in the Session API result. There is no channel that reveals more than another, and no way to widen the set after approval. The Session API returns every claim key in claims, with null for a claim your client isn’t approved for.

​
Not included

  • Address, company roles, income, property. Registry enrichment (SPAR, Bolagsverket, Skatteverket, Lantmäteriet) needs separate data licences and is not part of sajn Login.
  • Email and phone. BankID does not provide them. Collect them yourself if you need them.
  • Anything the user typed. Every claim originates from BankID, which is the point.