Additional security considerations

1522 views April 16, 2020 April 16, 2020 0

The base implementation of OIDC should be secure enough in most cases. This page mentions a few measures that can be taken to increase security, if desired.

In an OIDC flow, you will receive an access token that is signed by Signicat, which you have to use to fetch the user info response. The following table shows how Signicat supports message encryption and signing with OIDC.

Signing Encryption Content
ID token Signed according to specification. Optional, off by default. Example payload:

  "sub": "pc_Chm_FISDkwcSSryfWTpHgK3G6pax4",
  "acr": "urn:signicat:oidc:method:nbid",
  "aud": "demo-preprod",
  "nbf": 1568359576,
  "amr": "urn:ksi:names:SAML:2.0:ac:BankID-NO",
  "auth_time": 1568359476,
  "iss": "",
  "exp": 1568363176,
  "iat": 1568359576
User info response Optional, off by default. Optional, off by default. Contains all claims available from the scopes that the user has given consent to. Depends on the ID method.

Encryption algorithm: AES-128

Supported key length: 2048-bit (4096-bit too, if required)

Signature hash: SHA-256

Encryption of the request object

One of the options for increased security is Full Message-Level Encryption (MLE). This section explains the steps that must be followed to establish MLE with OIDC.


Before the implementation, you must provide Signicat with an encryption key, so that we can encrypt our responses with it. This key needs to be in a specific format. Follow these steps:

  1. Generate a JWK RSA pair (2048-bit). Signicat also supports 4096-bit if required. It is important that you create a JWK and not a PEM, CER, CRT, etc.

  2. Send the public part to Signicat. The public part can be sent through email, as it does not contain sensitive information.

Please note:

when we store your key in our system, a new Key ID (“kid”) will be generated. We will provide you with this new Key ID. You have to use this Key ID, as we do not have the ability to change the Key ID in our keystore.


You should send your requests as a normal OIDC request (see exception below). The difference between a normal OIDC flow and MLE flow are:

  1. The ID token and the response from user info is a nested JWT which is encrypted and signed.

    1. Decrypt it with your private key from the RSA pair given to Signicat.

    2. Deserialize the resulting signed JWT and verify the signature.

  2. The ID token must, as always, be verified according OIDC specifications.

Note: <ENV> equals for pre-production and your Signicat subdomain for production.

A functional example implementation of full message-level encryption can be found on GitHub. This example is related to FTN (Finnish Trust Network).

Encrypting Authorization Requests

Normally, authorization requests do not contain any personal data, and as such do not need to be encrypted. There are some unlikely edge-case scenarios where you might include personal data in the authorization request. If your implementation requires it, here’s what you should do:

Begin crafting the OIDC Authorization Request. The parameters are standard OIDC parameters. Examples of Authorization Request encryption in a number of common languages can be found at The requirements are as follows:

  • The HTTP request can be made using either GET or POST.

  • The payload must be a Request Object (per OIDC Core specifications, section 6.1). An example for a typical payload Request Object looks as follows: [payload example + value descriptions]

  • The request must be an encrypted JWT; which contains the aforementioned Request Object (as detailed on the OIDC specs).

  • The JWE token must be encrypted with the public key ("use":"enc") available at https://<ENV>

  • The protected header for the JWE token must contain the following claims:

    • "enc"="A128CBC-HS256"

    • "typ"="JWE"

    • "kid" and "alg" (the values for “kid” and “alg” are specified at https://<ENV>

Was this helpful?