To ensure a high level of security, HelseID uses a profile of the technical protocols that our core services are based on. This is a profile that is customized for high risk domains such as health, finance, eGov and banking etc. The HelseID security profile is based on the FAPI 2.0 Baseline profile, which is maintained by OpenID Foundation (OIDF). Be aware that there might be some minor differences between the FAPI 2.0 standard and HelseIDs profile due to practical considerations.
This security profile assumes that the reader is familiar with the roles and underlying protocols and specifications as described in the OAuth 2.1 framework and OpenID Connect.
Please note that some of the requirements are yet to be supported by HelseID.
HelseID will enforce these requirements in the future, but with due notice.
Absolute requirements for clients using HelseID
All clients
shall only establish connections to servers, including HelseID, using TLS. All TLS connections shall be set up using TLS version 1.2 or later, and follow RFC 7525.
shall be confidential clients, meaning that the client secrets used to authenticate the clients are known to HelseID prior to the authentication.
shall pass request parameters as JWT as described by OIDF in OpenID Connect, and as detailed by HelseID.
shall support client authentication using private_key_jwt”, as described by OpenID Connect for interactive sessions.
Se below for allowed algorithms
shall support sender-constrained tokens using “Demonstrating Proof-of-Possession at the Application Layer” (DPoP) as described by draft-ietf-oauth-dpop.
This is a future requirement and is not supported by HelseID yet
shall send access tokens in http authorization headers, as described by RFC 6750.
shall adhere to the updated version of “OAuth 2.0 Security Best Current Practice”.
Clients that supports user logon
shall use authorization code grant, as described by IETF in OAuth 2.0 and by OIDF in OpenID Connect for interactive sessions (end-user sessions).
shall use PKCE, as defined by IETF in RFC 76936 - Proof Key for Code Exchange, to mitigate against code interception and other attacks.
shall use the “authorization_details” structure, as defined by IETF in the specification Rich Authorization Requests, to convey fine grained authorization requirements to HelseID. These requirements are further detailed by HelseID here.
shall check the the validity of the “iss” parameter in the authorization response to prevent mix-up attacks.
shall implement protection against XSS and CSRF attacks. Please refer to external sources as OWASP for details about how to test and secure a client.
shall not expose to open redirectors where the client is vulnerable to malicious redirections . Please refer to external sources to find descriptions of mitigations to these types of attacks.
the client shall protect against attacks via HTTP Header
the client shall protect against attacks via Javascript (e.g. XSS attacks)
Clients that do not support user logon (machine to machine)
shall use the Client Credentials flow as described in RFC 6749.
shall use a client assertion to convey fine grained authorization information to HelseID. The process is described here.
Cryptography and secrets
All “secrets” (in practice private keys)
Cryptography
The following algorithms are supported when using “private_key_jwt” and request objects.
...
JSON Web Algorithm
...
Signature algorithm family
...
Hashing algorithm
...
RS256
...
RSASSA-PKCS1-v1_5
...
SHA-256
...
RS384
...
RSASSA-PKCS1-v1_5
...
SHA-384
...
RS512
...
RSASSA-PKCS1-v1_5
...
SHA-512
...
ES256
...
ECDSA
...
SHA-256
...
ES384
...
ECDSA
...
SHA-384
...
ES512
...
ECDSA
...
SHA-512
...
PS256
...
RSASSA-PSS
...
SHA-256
...
PS384
...
RSASSA-PSS
...
SHA-384
...
PS512
...
RSASSA-PSS
...
SHA-512
It is recommended to use PS256 or PS512
RSA shall have a minimum length of 2048 bits
Elliptic curve shall have a minimum length of 160 bits
References
Note that some of the links below might not point to the latest version of the document.
The OAuth 2.0 Authorization Framework: https://tools.ietf.org/html/rfc6749
OAuth 2.0 for Native Apps: https://tools.ietf.org/html/rfc8252
The OAuth 2.0 Authorization Framework - Bearer Token usage: https://tools.ietf.org/html/rfc6750
Proof Key for Code Exchange: https://tools.ietf.org/html/rfc7636
OpenID Connect: https://openid.net/specs/openid-connect-core-1_0.html
FAPI 2.0: https://openid.bitbucket.io/fapi/fapi-2_0-security-profile
OAuth 2.1: https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00
OAuth DPoP: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13
OAuth 2.0 Security Best Current Practice: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics This document has been moved. Please see the security profile at this page (Norwegian), or this page (English).