Additional Information

The following set of claims about the end user are available over the Userinfo endpoint, depending on the scopes and claims acturally requested by the OIDC Client. Among these claims is small set of basic claims duplicated from the ID Token. Additional claims beyond this basic set do as a rule-of-thumb demand explicit consent from the end-user. Note that the set of additional claims include both standardized and non-standardized elements. The non-standard claims are specific for the OIDC Provider from BankID and are indicated in the comment column of the below table.

m	Support	Example	Description	Comment	Editorial comment
sub		9578-5999-4-1765512	Subject Identifier	Duplicated from ID Token
name		Nilsen, Frode Beckmann	Full name	Duplicated from ID Token
gender			Gender	Duplicated from ID Token	Must be added
birthdate		1966-12-18	Birthdate	Duplicated from ID Token
given_name		Frode Beckmann	Given name (first name)
family_name		Nilsen	Surname (last name)
middle_name			Middle Name		Must be added
nickname			Casual name
preferred_username		Nilsen, Frode Beckmann	Shorthand name		Must be reviewed
profile			Profile page URL
picture			Picture URL
website			Homepage URL
email			Preferred email		Must be added
email_verified			Email verification status		Must be added
zoneinfo			Time zone
locale			Locale
phone_number		95871775	Preferred phone numer
phone_number_verified		false	Phone number verification status
address		{ "formatted": "Lybekkveien 11C\n0772 Oslo\nNorway", "country": "Norway", "street_address": "Lybekkveien 11C", "postal_code": "0772", "locality": "Oslo", "house_number": "11", "house_letter": "C", "street_name": "Lybekkveien" }	Postal address
all_phone_numbers		{"number":"95871775","number_verified":false},{"number":"46897469","number_verified":false},{"number":"94782958","number_verified":false}

---

BankID OIDC also integrates with a service to provide additional information like private address and phone number for the end-user being authenticated.

ontains a consent dialog allowing the user to accept or deny use of any additional information the BankID OIDC Service may provide. 

Characteristics of BankID OIDC access_tokens

Resources managed/authorized by the BankID OIDC Service get a “public” access_token (“one access_token to rule them all”). When an OIDC Client uses scope (or default scope) to define what resources it needs authorization for, the issued access_token can be used for all those resources. The resources must call the introspect endpoint in order to verify that it is the correct audience/resource for this access_token as well as getting returned the access_token contents/claims. Resources are expected to cache/cookie this information so there’s no need to call introspect for every incoming request with the same access_token.

The introspect endpoint demands basic authentication with the resource’s client_id and client_secret so that it knows what resource it is dealing with. 

Another policy is to have “private” access_tokens. That means each resource has their own access_token issued and encrypted with their client_secret/resource_secret. This would remove the need to call introspect in order to validate and get claims, but it will be difficult for the client to keep track of all the access_tokens issued to individual resource services. AAD is doing this and using the refresh_token to ask for more scope (new resources). This would work as long as the refresh_token is issued for the same resource owner (end-user).

"Private access_tokens" are currently not supported. Refresh_tokens are also not implemented. The rationale is that the supported “public” implementation is considered to more efficient (provided the caching we mentioned).