Finland OpenID Connect Detailed Analysis - RUB-NDS/FutureTrust GitHub Wiki
Finland specifies the usage of OpenID Connect’s authorization code flow.
In the first step, a user accesses some Service Provider (SP). According to the documentation, FTN corresponds to an SP (see Figure 1).
Since the user is not authenticated yet, FTN generates an authentication request and redirects the user to the Identity Provider (IdP).
The authentication request contains the following HTTP GET parameters:
| Parameter | Description |
|---|---|
| location=https://server.example.com/authorize? | The authorization endpoint as set up by the FTN administrator. An SP passes the authentication request to this location. |
| response_type=code | This value must be set to code to indicate use of the OIDC Authorization flow. |
| &client_id=<CLIENT_ID> | This value is a unique SP identifier assigned to the SP by the FTN Authentication Broker administrator. |
| &redirect_uri=<SP_URL> | This value is the redirection URI where FTN Authentication Broker will send the authentication response. This value must match the URI provided to the FTN Authentication Broker administrator during SP on boarding. |
| &scope= | This value must include openid to indicate the use of the OpenID protocol. An SP can also specify an attribute group index to request user attributes. The attribute group index is assigned by the FTN Authentication Broker administrator. |
| &state= | This value is a unique SP supplied opaque value used to maintain state between the request and response. |
| &nonce= | NONCE is string value used to associate a SP session with an ID Token, and to mitigate replay attacks. |
| &arc_values= | eIDAS Level of Assurance. |
Tabel 1: HTTP GET parameters used in an authentication request
Figure 1: Finland eID Service: OpenID Connect authentication flow
Once, the user authenticates at the IdP, the authentication response is sent. It contains the following parameters:
| Parameter | Description |
|---|---|
| location=<AS_URL> | OIDC call-back. The redirect URI as specified by the SP in the request and during SP on boarding. |
| code=<AUTHZ_CODE> | Created authorization code. This value is the Authorization Code that the SP can use to retrieve the authentication claim. |
| state= | State value from original authentication request. |
Table 2: HTTP parameters used in an authentication response message
To obtain the Access Token and the ID Token, the SP sends a token request to the IdP Token Endpoint. The token request must be defined by using JWT assertions. It contains the following parameters:
| Parameter | Description |
|---|---|
| redirect_uri | This value is the redirection URI where FTN Authentication Broker will send the authentication response. This value must match the URI provided to the FTN Authentication Broker administrator during SP on boarding. |
| grant_type = authorization_code | This value is set to authorization_code. |
| client_id | <CLIENT_ID>, from client registration, encoded as HTTP basic authorization header. |
| client_secret | <CLIENT_SECRET>, from client registration, encoded as HTTP basic authorization header |
| code | This value is the Authorization Code. |
| client_assertion_type | urn:ietf:params:oauth:client-assertion-type:jwt-bearer |
| client_assertion | A JWT generated by the SP and signed by its private key. |
Table 3: Token request parameters
If the token request is valid, the IdP generates the token response. It contains the following parameters:
| Parameter | Description |
|---|---|
| access_token = <ACCESS_TOKEN> | This value is used to retrieve any attributes from the FTN Authentication Broker User Info Endpoint, if requested. |
| token_type | This value is set to Bearer xi |
| expires_in | 3600 |
| refresh_token | <REFRESH_TOKEN> |
| id_token | <ID_TOKEN> This value is a signed (and optionally encrypted) JSON Web Token (JWT) containing details about the authentication claim. |
Table 4: Token response parameters
The ID Token contains all required values specified by the OpenID Connect specification. The SP must validate the ID Token.
Afterwards, the SP can request further claims by sending the access_token to the IdP.
The request contains the parameters: location, host, and access_token.
If the access_token is valid, the IdP returns a user Info response as JWT, containing the requested attributes. The user Info response can be optionally encrypted.
