Open Government, Denmark Authentication Methods & Security (2026)

Authentication overview

Open Government, Denmark is an initiative by the Danish Agency for Digital Government (Digitaliseringsstyrelsen) focused on establishing policies and principles for making public sector data openly available to foster transparency and innovation. Because Open Government, Denmark itself serves as a framework and a portal to various data sources rather than a single direct API provider, authentication mechanisms are typically implemented at the level of the individual data-providing agencies and their specific APIs or data portals. This distributed model means that developers and users will encounter a range of authentication methods depending on the particular dataset or service they wish to access. The overarching goal is to ensure secure, authorized, and auditable access to sensitive public information while maintaining ease of use for developers and citizens.

The Danish public sector places a high emphasis on digital security and user identity. For citizen-facing services and portals, the national eID solutions, such as MitID and its predecessor NemID, are standard for authentication. For programmatic access to APIs, methods like API keys, OAuth 2.0, and OpenID Connect (OIDC) are prevalent, aligning with common industry practices for secure API access. These methods facilitate both user authentication (verifying identity) and authorization (granting permissions to specific resources). Understanding the specific requirements of each data source is crucial for successful integration, as outlined in their respective documentation. The Danish Agency for Digital Government provides general guidance on digital security and infrastructure, which informs the authentication practices across the public sector, as detailed in their Open Government policy documentation.

Supported authentication methods

The authentication methods supported by Open Government, Denmark's various data sources are diverse, reflecting the autonomy of individual agencies in implementing their data access solutions. However, common patterns emerge across the Danish public sector for both human-user and machine-to-machine interactions. The choice of method often depends on the sensitivity of the data, the type of client accessing it, and the required level of authorization granularity.

For direct human interaction with portals and web services, the national eID systems are foundational:

• MitID: The current national electronic ID system in Denmark, providing secure login and digital signatures for citizens and businesses. It is widely used across public and private sector services for strong authentication.
• NemID: The predecessor to MitID, still supported by some legacy systems but being phased out. It served a similar function for secure identification and digital signing.

For programmatic access to APIs and data feeds, developers typically encounter:

• API Keys: A simple method where a unique key is provided as a token in request headers or query parameters. Suitable for accessing public or less sensitive data where identifying the client application is sufficient.
• OAuth 2.0: An industry-standard protocol for authorization that allows third-party applications to obtain limited access to user accounts on an HTTP service. It separates the roles of authentication (handled by an identity provider) and authorization (handled by the resource server). This is often used when an application needs to access data on behalf of a user. The OAuth 2.0 specification is maintained by the IETF.
• OpenID Connect (OIDC): An authentication layer on top of OAuth 2.0, allowing clients to verify the identity of the end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user. OIDC is commonly used for single sign-on (SSO) scenarios and when an application needs to know the user's identity. The OpenID Connect specification provides further details on its implementation.

The following table summarizes these methods:

Getting your credentials

The process for obtaining credentials for Open Government, Denmark data sources is decentralized, as each data-providing agency manages its own access mechanisms. Therefore, the first step is always to identify the specific dataset or API you wish to use and then consult its dedicated documentation. The Open Government, Denmark portal serves as a starting point, often linking to specific agency portals where data is hosted.

General steps typically include:

1. Identify the Data Source: Navigate through the Open Government, Denmark resources to find the specific agency or service responsible for the data you need. Examples include Statistics Denmark (Danmarks Statistik), the Danish Business Authority (Erhvervsstyrelsen), or local municipalities.
2. Locate API Documentation: Once the data source is identified, search for their developer portal, API documentation, or data access guidelines. This documentation will detail the available authentication methods and the process for obtaining credentials.
3. Registration/Application:
   • For API Keys: You may need to register an account on the agency's developer portal. Upon registration, an API key is often generated automatically or can be requested. Some agencies might require an application process to explain your use case.
   • For OAuth 2.0 / OIDC: You will typically need to register your application with the agency's identity provider or authorization server. This involves providing details such as your application's name, redirect URLs, and contact information. Upon successful registration, you will receive a client_id and a client_secret. These are critical for initiating the OAuth flow. For example, Google's documentation on OAuth 2.0 for Web Server Applications provides a general overview of this process, which is similar across many providers.
   • For MitID/NemID: As these are national eID solutions, citizens and businesses obtain them through official channels, typically banks or the Danish Agency for Digital Government. Applications integrating with services requiring MitID will use standard OIDC flows where MitID acts as the identity provider.
4. Accept Terms of Service: Many data providers require agreement to specific terms of service or data usage policies before granting access to credentials.

Always treat your credentials (API keys, client secrets) as sensitive information and store them securely, following best practices for secret management.

Authenticated request example

Since the specific authentication method and API endpoint vary greatly between data providers under the Open Government, Denmark initiative, a generic example demonstrating an API Key or OAuth 2.0 token usage is provided. Developers should adapt this based on the specific API documentation they are consulting.

Example 1: API Key in Header

Many APIs require an API key to be sent in a custom HTTP header, often named X-API-Key or Authorization with a specific scheme like Bearer if it's a token-like key.

curl -X GET \
  'https://api.example.gov.dk/data/v1/datasets/population?year=2024' \
  -H 'X-API-Key: YOUR_API_KEY_HERE' \
  -H 'Accept: application/json'

In this example:

• https://api.example.gov.dk/data/v1/datasets/population?year=2024 is a placeholder for an actual API endpoint from a Danish government agency.
• YOUR_API_KEY_HERE must be replaced with the API key obtained from the specific data provider.
• The Accept: application/json header indicates that the client expects a JSON response.

Example 2: OAuth 2.0 Bearer Token

For APIs protected by OAuth 2.0, you first need to obtain an access token using an appropriate OAuth flow (e.g., Client Credentials, Authorization Code). Once you have the access token, it is typically included in the Authorization header with the Bearer scheme.

# Step 1: Obtain an Access Token (conceptual - actual steps vary by OAuth flow)
# This would involve making a request to an authorization server's token endpoint.
# For example, using the client credentials flow:
# curl -X POST \
#   'https://auth.example.gov.dk/oauth/token' \
#   -H 'Content-Type: application/x-www-form-urlencoded' \
#   -d 'grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET'

# Assuming you have obtained an access token like 'YOUR_ACCESS_TOKEN_HERE'

# Step 2: Make an authenticated API request using the access token
curl -X GET \
  'https://api.example.gov.dk/data/v1/secure_datasets/health_records' \
  -H 'Authorization: Bearer YOUR_ACCESS_TOKEN_HERE' \
  -H 'Accept: application/json'

In this OAuth 2.0 example:

• YOUR_ACCESS_TOKEN_HERE is the token acquired from the authorization server. Access tokens usually have a limited lifespan and must be refreshed periodically.
• The Authorization: Bearer header is the standard way to send an OAuth 2.0 access token.
• The example endpoint https://api.example.gov.dk/data/v1/secure_datasets/health_records represents a protected resource.

Always refer to the specific API's documentation for exact endpoint URLs, required headers, and authentication flow details.

Security best practices

When interacting with Open Government, Denmark data sources, adhering to robust security practices is essential to protect both your application and the integrity of public data. Given the sensitive nature of some government data, developers should implement comprehensive security measures.

• Secure Credential Storage: Never hardcode API keys or client secrets directly into your application's source code. Use environment variables, secure configuration files, or dedicated secret management services (e.g., AWS Secrets Manager, Azure Key Vault, Google Secret Manager) to store credentials. This prevents exposure if your code repository is compromised.
• Use HTTPS/TLS: Always ensure all communication with API endpoints occurs over HTTPS (TLS). This encrypts data in transit, protecting credentials and data payloads from eavesdropping and man-in-the-middle attacks. Most modern API clients and libraries enforce HTTPS by default, but it's crucial to verify.
• Least Privilege Principle: Request only the minimum necessary permissions (scopes) when using OAuth 2.0. Grant your application only the access required to perform its intended function, reducing the potential impact of a compromise.
• Regular Key Rotation: Periodically rotate API keys and client secrets. This practice limits the window of opportunity for an attacker to use a compromised credential. Consult the specific agency's documentation for their recommended rotation frequency and procedure.
• Error Handling without Leaking Information: Implement robust error handling that provides useful information to your application without exposing sensitive details (e.g., internal server errors, stack traces, or full authentication tokens) to end-users or logs that might be publicly accessible.
• Validate Input and Output: Always validate data received from and sent to APIs. This prevents common vulnerabilities such as injection attacks and ensures data integrity.
• Monitor and Audit: Implement logging and monitoring for API access. Track successful and failed authentication attempts, data access patterns, and any unusual activity. This helps in detecting and responding to potential security incidents promptly.
• Rate Limiting and Throttling: Be aware of and respect any rate limits imposed by the APIs. While primarily for service stability, exceeding limits can sometimes trigger security measures or lead to temporary blocks. Implement client-side rate limiting to prevent accidental abuse.
• Keep Dependencies Updated: Regularly update all libraries, frameworks, and components used in your application to their latest versions. This helps patch known security vulnerabilities.
• Educate Developers: Ensure that all developers working on the project are aware of and follow these security best practices. Regular security training can significantly reduce the risk of vulnerabilities.

By following these guidelines, developers can contribute to a secure and reliable ecosystem for accessing Danish public sector data, aligning with the principles of Open Government, Denmark.