Skip to content

Flows

The OAuth 2.0 Authorization Framework specifies a protocol, or flows, for interaction between resource owners (users), clients (applications), authorization servers and resource servers.

This protocol is based on the use of Access tokens, as a way for the client to request an end user's protected resources with the end user's approval, without compromising or exposing the end user's credentials.

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

Accordingly, an authorization grant is a method for which the client can obtain the Access token needed to get the end user's data.

The BankID OIDC Provider supports two grant types:

These flows are used independently or combined in our different products. PAdES and SEID-SDO signing, for example, start out with a client credential flow (where the Access token is used to create and upload the sign order), followed by an authorization code flow (where the Access token is used to download the completed sign order from the resource server).

Authorization Code Flow

The authorization code flow concerns the authentication of end users, followed by an ID Token with the end-user data and an Access Token that may access to other BankID resource servers. In short;

  1. The end user authenticates, and is returned to the client via the redirectURL
  2. The client receives an authorization code from the BankID OIDC provider (B), and uses this in exchange for tokens via the Token endpoint (C/D)
    1. The ID Token identifies the user
    2. The Access Token can be used to access other resource servers (E/F)
    3. The Refresh token can be used to issue new Access tokens

Client Credential Flow

The client credential flow concerns authorization of access to BankID resource servers directly from an OIDC Client, without involving an end-user. In short;

  1. The client requests an Access token from the BankID OIDC provider (C)
  2. If the client credentials are valid (see client authentication), the client receives an Access token (D), which can be used to request other resources (E/F)