API version: 2.0
Vipps Login is to a large degree based on the OAuth2 and OpenID Connect standards. Some core concepts related to these are presented below.
OAuth 2.0 is the industry-standard protocol for authorization. Giving a proper introduction to the standard is out of the scope of this documentation, but there are many excellent resources on the web. If you are new to the subject we recommend this talk by Nate Barbettini at Okta. We also recommend reading OAuth 2 Simplified and having a look at the documentation.
Open ID Connect
OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in a REST-like manner.
Some good sources to get you started are: Identity, Claims, & Tokens – An OpenID Connect Primer and OpenID Connect explained.
Supported OpenID Connect Flows
Authorization Code Grant
The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
For more information see RFC-6749 section 4.1.
The ID token is a signed information object representing the authenticated identity of the user. As part of the OpenID Connect standard, the ID token is encoded as a JWT and signed using the JWS standard. The ID Token can be decoded for debugging purposes by tools such as jwt.io.
You can read more at the OIDC standard.
It is important to validate the Id-token before using any data contained in it. See the OIDC standard on Id-token validation for the specifics. We recommend that you use a library for this. A good place to start is finding a library for your language at jwt.io.
Access tokens are random strings that represent the authorization of a specific application to access specific parts of a user’s data.
These access tokens are provided by the access-management-1.0/access/oauth2/token endpoint. The token itself does not provide any information, but it can be used to fetch the data that the end-user has consented to share from the userinfo endpoint. Access tokens must be kept confidential in transit and storage.
For more information see RFC-6749 section 4.1.3-4.1.4.
Vipps Login does not currently support refresh tokens.
Token endpoint authentication method
The token endpoint is a standard OIDC endpoint used for requesting Access and ID Tokens.
The default token endpoint authentication method is
It is possible to change the authentication method to
client_secret_post in the Vipps portal. This setting will then apply to all login transactions on this sales unit.
Go to How can I use client_secret_post for authentication? for more information on how to change the authentication method.
Scopes are space-separated lists of identifiers used to specify what access privileges are being requested. Vipps Login currently supports the following scopes:
|Scopes||Description||User consent required|
|openid||This is the scope used to request an Id-token. It provides the claim ||no|
|address||The user can have up to three addresses in Vipps: home, work and other. User addresses are given as claims ||yes|
|birthDate||User birthdate (verified with National Population Register)||yes|
|User email (verified). The flag ||yes|
|name||User first, middle, and given name (verified with National Population Register)||yes|
|phoneNumber||Verified phone number (verified - the number used with Vipps)||yes|
|nin||Norwegian national identity number (NIN) (verified with National Population Register). Note, merchants need to apply for access to NIN. See Who can get access to NIN and how? for more information.||yes|
|delegatedConsents||Enabled consents to be collected on behalf of a merchant. This scope is only supported in Vipps login from phone number, see Merchant delegated consents.||yes|
When requesting scopes that require user consent, a view listing these scopes will be displayed to the user with the option to allow or deny the consent request. This view is skipped if no scopes requiring consent are requested. The user can not make changes to the list of requested scopes, and can therefore not accept for example name and deny address.
We recommend asking for the minimal number of scopes needed for your use case to minimize the number of users that deny the consent request.