Security profile for HelseID-clients and APIs
This document outlines the standards required for any software intending to utilize the HelseID service.
| Terms | |
|---|---|
| HelseID | An authorization server, as described in RFC 6749. Used to secure national APIs within the healthcare |
| Client | A client as defined in RFC 6749. In the context of HelseID, a client is a software installation that adheres to this security profile. |
| Confidential Client | Confidential clients are capable of maintaining the confidentiality of a client secret. All clients utilizing HelseID must authenticate using such a secret. Any client using HelseID must be a confidential client. |
| Client Authentication | The process by which a client proves its identity to the authorization server. In HelseID, this is always performed by signing a JWT with a private key, such that the corresponding public key is registered with HelseID. |
With the exception of a few differences introduced to facilitate the use of HelseID within the healthcare sector, the HelseID security profile follows the FAPI 2.0 Security Profile. The differences are as follows:
- HelseID permits a locally installed thick client to be considered a confidential client.
- MTLS for client authentication is not supported.
- "Consent" (user consent for using HelseID for login) is not required.
- HelseID imposes explicit requirements for general web security; at a minimum, we expect compliance with the OWASP Top 10.
- For applications supporting both local login and login via HelseID, we require mechanisms to ensure that both logins are performed by the same individual.
HelseID distinguishes between security requirements and functional requirements. The purpose is to facilitate separation between the security requirements derived from the FAPI 2.0 profile and NHN’s own functional requirements. The security requirements are mandatory and must be adhered to by all clients and APIs integrating with HelseID. The functional requirements are also mandatory, although deviations may be considered in certain cases.
As an extension of the security profile we have published this document that explains the reasoning behind the requirements.