Use of Client Secrets

Secrets are used in HelseID for client authentication, as well as for generating DPoP proofs. You may use the same secret (private key) for both of these purposes if it is appropriate.

The private key must be well protected, but HelseID allows it to be reused across components within the same system. The boundaries of "the same system" are for the system provider to define, but the following guidelines apply:

• For a locally installed software, the boundary is the local machine, or the database used
• For a locally installed software with a backend shared within the same enterprise, the boundary is the local machine plus the shared backend and the database
• For a distributed system, the boundary is typically the internal network where the different components run (e.g., internally in a Kubernetes cluster or within a closed virtual network)

To be able to use DPoP, the client must have a private key that it uses both to create DPoP proofs for calls to HelseID and then DPoP proofs for calls to an API. The same private key must be used as long as the Access token is valid. In a distributed architecture, there may be different components that perform client authentication and the creation of DPoP proofs. HelseID allows the same private key to be used across the components in the system as long as they are only accessible in a closed network.

Usage Patterns Where the Provider Can Choose Management of Secrets:

The three figures below show examples of where the boundary of a system in the context of using HelseID is. Within the blue frame (either a local rich client, or an internal closed network), a software provider is free to choose how they handle secrets.

Locally Installed Software

In this pattern, the client software is installed on a single computer (rich client), which also stores information in a local database:

Locally Installed Software with Shared Backend

In this pattern, the client software is installed on multiple computers, each using a shared backend/server to store information in a common database:

Distributed Software

In this pattern, a service is made public for multiple users, regardless of which computers they use to access the service. The service has connections to both the public network and a closed internal network:

A Usage Pattern Where the Provider Cannot Share Secrets Between Different Components:

The figure below shows a distributed system that spans multiple networks; in this case, the secret must be secured and cannot be shared between different components across distinct networks.