Signing
The OIDC Provider from BankID supports signing of the following data elements:
- ID Tokens
- Default Access Tokens
- Default Refresh Tokens
- Responses from the TINFO service
Asymmetric keys are used for signing according to details described in Jwk. OIDC Clients must validate signatures as part of token validation to ensure that tokens are not tampered with after being issued by the OIDC Provider from BankID. The same applies for validation of responses for the TINFO resource server.
Keys used for signing are marked with
"use":"sig"
Verification
The OIDC provider from BankID verifies the following data elements:
- request authorize parameter
- private_key_jwt client_assertion object
To support this validation, a jwks_uri must be registered for the given oidc client, such that BankID OIDC provider can retrieve validation keys.
Encryption
Encryption of parameters containing personal information may be mandatory in the future.
The OIDC provider from BankID supports decryption of the following element(s):
- login_hint
- request authorize parameter
This login_hint encryption is a BankID OIDC proprietary functionality. Encryption of the request parameter, which was introduced later, is sufficient since the login_hint may be placed inside a request parameter. The login_hint encryption is therefore deprecated.
Asymmetric keys are used for encryption according to details described in Jwk. OIDC Clients may encrypt the value of the login_hint to ensure that personal information is not leaking in the user agent history.
Remark that the encryption keys for login_hint are published through the BankID OIDC specific jwks_uri_enc while encryption keys for the request parameter are publish through the OIDC standard jwks_uri.
Using an encrypted request parameter makes the initial authorize request to BankID OIDC confidential. Later in the internal redirect flow between BankID OIDC components, values from the request object may be shown in cleartext. See known issues (C12).
Keys used for encryption are all marked with
"use":"enc".
Encryption algorithms supported are:
login_hint | request parameter | ||
Alg | Enc | Alg | Enc |
---|---|---|---|
ECDH-ES | A128GCM | RSA1_5 | See openid-configuration document |
RSA-OAEP | A128CBC-HS256 | RSA-OAEP | See openid-configuration document |
RSA-OAEP-256 | A128CBC-HS256 | RSA-OAEP-256 | See openid-configuration document |
The encrypted login_hint should be formatted as a JWE Compact Serialization. The ciphertext is the encrypted plaintext login_hint.
The encrypted request parameter should be formatted as a JWE Compact Serialization. The ciphertext is the request parameter as a signed JWT
Example
A typical login hint:
login_hint=BID:14025800177
will using the encryption key in the Jwk example, be:
login_hint=eyJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIsIngiOiJjSm1XTWtrcXlWUDYtbFcya3hoSElUZG5oNkR1MkNzUklZZzBja3lXdVdBIiwieSI6IlRpbDROMFlGNWFSNnJJUWpHRjY4cWRkQ2ZfcDJuVmJCM1RMY2U2bDNxVlkifSwia2lkIjoiZW5jcnlwdGtleSIsImVuYyI6IkExMjhHQ00iLCJhbGciOiJFQ0RILUVTIn0..DzbBsb5mQSl-S-zG.-hL1oyZNRrqkp4UJHxX_.Q0n47mXdkmAoDfSqu-vkEg
The header part of the JWE object is in this case:
{ "epk": { "kty": "EC", "crv": "P-256", "x": "cJmWMkkqyVP6-lW2kxhHITdnh6Du2CsRIYg0ckyWuWA", "y": "Til4N0YF5aR6rIQjGF68qddCf_p2nVbB3TLce6l3qVY" }, "kid": "encryptkey", "enc": "A128GCM", "alg": "ECDH-ES" }
BankID OIDC provider will use the kid value to extract the correct key for decryption. If the kid value is not set, the decryption will fail.
The message to be encrypted is not JSON, it is simply:
BID:14025800177