OpenID Connect Profile for Sweden Connect
Version 1.1 – 2026-09-03 – Draft
Registration number: 2024-7674
Copyright © The Swedish Agency for Digital Government (Digg), 2015-2026. All Rights Reserved.
Table of Contents
-
1.1. Requirements Notation and Conventions
1.2. Conformance
-
2.1. OpenID Provider Discovery and Metadata Requirements
2.2. Authentication Request Requirements
2.2.1. Single Sign-on Processing
2.2.2. User Message Request Parameter
2.2.3. Requested Authentication Provider Parameter
2.3. Token Endpoint Requirements
2.3.1. Client Authentication Requirements
2.3.2. Token Response Requirements
1. Introduction
This profile is an extension of The Swedish OpenID Connect Profile, [OIDC.Sweden.Profile], for the Sweden Connect identity federation.
The profile aims to get a baseline security and to facilitate interoperability between relying parties and OpenID providers within the Sweden Connect identity federation.
1.1. Requirements Notation and Conventions
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in [RFC2119].
These keywords are capitalized when used to unambiguously specify requirements over protocol features and behaviour that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.
1.2. Conformance
This profile defines requirements for OpenID Connect Relying Parties (clients) and OpenID Providers (identity providers), and the interaction between them.
Components compliant with this profile MUST adhere to the requirements of The Swedish OpenID Connect Profile, [OIDC.Sweden.Profile] along with the extensions and requirements stated in the rest of this profile.
2. OpenID Provider Requirements
An OpenID Provider compliant with this profile MUST adhere to the requirements stated in [OIDC.Sweden.Profile] along with the additions declared below.
2.1. OpenID Provider Discovery and Metadata Requirements
The following requirements concerning OpenID Provider Metadata documents apply in addition to section 5.2 of [OIDC.Sweden.Profile]:
The OP Metadata document SHOULD contain a
service_documentationparameter having as its value a URL pointing to a resource containing human-readable information about the OP (for example, information about client registration). See section 3 of [OpenID.Discovery].The OP Metadata document MUST contain the
ui_locales_supportedparameter, and its value MUST contain English (en) and Swedish (sv), and MAY contain support for other languages. See section 3 of [OpenID.Discovery].
Note: This version of the profile does not specify how OpenID Provider Metadata documents are made available to the Relying Parties/Clients of the federation. Future versions will include OpenID Federation and alternative mechanisms for distributing metadata.
2.2. Authentication Request Requirements
2.2.1. Single Sign-on Processing
Sweden Connect is a national identity federation and the Relying Parties of the federation generally have no organizational affinity, other than they use the same OpenID Providers for authentication of their users. Therefore, the feature of Single Sign-on by relying on a user's security context/session at an OpenID Provider that is used by several, non-connected, Relying Parties, should be used with great care.
This profile states the following requirements regarding the re-use of user sessions:
An OpenID Provider within the Sweden Connect federation MUST NOT allow user sessions to exceed 60 minutes.
If the
promptparameter is not present in an authentication request, the OpenID Provider MUST treat this request as if it would contain thepromptparameter with a value oflogin, meaning that a user (re-)authentication is required, no matter the state of the current user session at the provider.If the
promptparameter is present and its value is set tonone(meaning that the Relying Party wishes to make use of an existing user security context/session, i.e., SSO), the following requirements apply:- If the security context/user session has expired, the OP MUST respond with an error holding the error code
login_required. - If the original authentication process, which led to the establishment of the security context, was created based on the request from another Relying Party than the sender of the current request, the OP MUST respond with an error holding the error code
login_required.
The exception to this requirement is that an OP is allowed to maintain a configuration of "groups of Relying Parties", where SSO is allowed. How this configuration is maintained is out of scope for this profile. - If the original authentication process, which led to the establishment of the security context, was performed using another authentication method or
acr(Authentication Context Class Reference) than what is requested in the current authentication request, the OP MUST respond with an error holding the error codelogin_required. - If the original authentication process, which led to the establishment of the security context, involved user consent for a set of claims, and the current authentication request contains a request for a different set of identity claims, the OP MUST respond with an error holding the error code
interaction_required.
- If the security context/user session has expired, the OP MUST respond with an error holding the error code
See section 3.1.2.1 of [OpenID.Core] and section 2.1.4 of [OIDC.Sweden.Profile] regarding further requirements for the prompt request parameter.
2.2.2. User Message Request Parameter
It is RECOMMENDED that OpenID Providers compliant with this profile supports the https://id.oidc.se/param/userMessage request parameter according to section 2.1 of [OIDC.Sweden.RPar]. This parameter gives the Relying Party the possibility to request that a message (set by the RP) is displayed to the user during the authentication process.
OpenID Providers that support the https://id.oidc.se/param/userMessage request parameter MUST include the https://id.oidc.se/disco/userMessageSupported parameter in its Metadata document (see section 3.3.1 of [OIDC.Sweden.RPar]). If MIME types other than text/plain is supported, the OP MUST include the https://id.oidc.se/disco/userMessageSupportedMimeTypes parameter and as its value state all supported MIME types.
2.2.3. Requested Authentication Provider Parameter
An OpenID Provider that acts as a proxy for underlying authentication mechanisms SHOULD support the https://id.oidc.se/param/authnProvider request parameter extension (see section 2.2 of [OIDC.Sweden.RPar]).
OpenID Providers that support the https://id.oidc.se/param/authnProvider request parameter, MUST declare this support in its Metadata document using the https://id.oidc.se/disco/authnProviderSupported parameter, see section 3.2 of [OIDC.Sweden.RPar].
2.3. Token Endpoint Requirements
This section extends section 3 of [OIDC.Sweden.Profile] with additional requirements for Token endpoint requests and responses.
2.3.1. Client Authentication Requirements
The following requirements apply in addition to the requirements stated in section 3.1.1 of [OIDC.Sweden.Profile].
In the context of the Sweden Connect federation, the OpenID Provider MUST NOT accept any other client authentication methods than private_key_jwt, or, if a bilateral agreement exists with a Relying Party, mutual TLS authentication.
Mutual TLS authentication may be tls_client_auth or self_signed_tls_client_auth, and the requirements stated in section 2 of [RFC8705] MUST be followed.
2.3.2. Token Response Requirements
The contents of the Access Token issued in a Token response MUST NOT reveal any information about the user's identity or the authentication process.
Section 4.2 of [OIDC.Sweden.Profile] states:
An OpenID Provider compliant with this profile MUST NOT release any identity claims in the ID Token, or via the UserInfo endpoint, if they have not been explicitly requested via scope and/or claims request parameters, or indirectly by a policy known, and accepted, by the involved parties.
If the Access Token is a cleartext JWT holding user identity data, information that the Relying Party may not be authorized to access may be leaked. Therefore, it is RECOMMENDED that opaque strings are used as Access Tokens.
Note: An OpenID Provider that also acts as an OAuth2 Authorization Server may of course issue JWT Access Tokens. The above requirement only applies to the Access Tokens that are issued during authentication (i.e., for granting access to the UserInfo endpoint).
2.4. Signature Extension Support
Section 7 of [SC.SAML.Profile] specifies that a SAML Identity Provider compliant with Sweden Connect needs to support the "authentication for signature" feature. By doing so, a Signature Service that acts as a Relying Party against the Identity Provider can request the user's approval for a signature, meaning that a sign message is displayed by the Identity Provider during user authentication.
Consequently, a Sweden Connect OpenID Provider, i.e., an OpenID Provider compliant with this profile, MUST support the "Signature Extension for OpenID Connect" specification [OIDC.Sweden.Sign] with the following additions and clarifications:
The OpenID Provider MUST support the Signature Approval use case as defined in Section 2.2 of [OIDC.Sweden.Sign], and MAY support the Signing use case as defined in Section 2.1 of [OIDC.Sweden.Sign].
The OpenID Provider MUST display a user interface for the user (directly or via an authentication device) that makes it clear that the user is performing a signature operation.
The OpenID Provider MUST NOT save the user's authentication in its session at the OP for later re-use in SSO scenarios. This requirement exists to prevent the authentication from a signature approval operation from being re-used when an ID Token is issued for a later authentication request.
See also Section 5.3 of [SC.OIDC.Metadata] for a clarification of metadata requirements regarding OpenID Provider signature extension support.
3. Relying Party Requirements
An OpenID Connect Relying Party (Client) compliant with this profile MUST adhere to the requirements stated in [OIDC.Sweden.Profile] along with the additions declared below.
3.1. Authentication Request Requirements
For all authentication requests where the Relying Party expects the user to authenticate itself, the RP SHOULD include the prompt request parameter and assign the login value. This is to prevent un-wanted SSO. See section 2.1.4 of [OIDC.Sweden.Profile].
It is RECOMMENDED that Relying Parties send authentication requests containing Request Objects, i.e., the request parameters are included in a JWT, and its encoding is assigned to the request parameter according to section 6.1 of [OpenID.Core]. It is also RECOMMENDED that the Request Object JWT is signed.
The above recommendation gives a higher level of security, and may be changed to an imperative requirement in future versions of this profile.
3.2. Client Registration and Metadata Requirements
Relying Parties compliant with this profile MUST follow the requirements stated in section 6 of [OIDC.Sweden.Profile] with the additions stated below.
The Relying Party/Client metadata MUST contain the following additional parameters:
The
contactsparameter holding at least one email address of people/groups responsible for the Relying Party.The
client_nameparameter holding the client presentation name. This name may be presented to the end-user by the OpenID Provider during authentication. The name MUST be given in Swedish (sv) and English (en).The
logo_uriparameter containing a URL referencing a logotype for the Relying Party. This logotype may be displayed by the OpenID Provider for the end-user during authentication. The URL MUST use the HTTPS-scheme and point to a valid image file. It is RECOMMENDED that the image file is in SVG-format. The parameter MAY be given for different languages.The
client_uriparameter containing a URL that is the home page for the Relying Party. This link may be used by the OpenID Provider when interacting with the user. The URL MUST use the HTTPS-scheme and point to a valid web page. The parameter MAY be given for different languages.
Also, it is RECOMMENDED, that a Relying Party includes the organization_name claim and provides its human-readable organization name in Swedish and English. See section 5.2.2 of [OpenID.Federation].
Example:
{
...
"contacts": [
"operations@example.com"
],
"client_name#en": "The Example Service",
"client_name#sv": "Exempeltjänsten",
"logo_uri": "https://www.example.com/logo.svg",
"client_uri#en": "https://www.example.com",
"client_uri#sv": "https://www.example.com/sv",
"organization_name#en" : "Example Organization",
"organization_name#sv" : "Exempelorganisationen"
...
}See further requirements concerning client metadata in section 2 of [OpenID.Registration].
Note: This version of the profile does not specify how client metadata is registered at/distributed to the OpenID Providers of the federation. Future versions will include OpenID Federation and alternative mechanisms for distributing client metadata.
4. Security Requirements
Entities compliant with this profile MUST adhere to [SC.Security] as well as Section 7 of [OIDC.Sweden.Profile], where the requirements from [SC.Security] take precedence in case of conflicting requirements.
5. References
Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997.
[Sakimura, N., Bradley, J., Jones, M., de Medeiros, B. and C. Mortimore, "OpenID Connect Core 1.0", August 2015] (https://openid.net/specs/openid-connect-core-1_0.html).
Sakimura, N., Bradley, J., Jones, M. and E. Jay, "OpenID Connect Discovery 1.0", August 2015.
Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT)”, May 2015.
Claims and Scopes Specification for the Swedish OpenID Connect Profile - Version 1.0.
Authentication Request Parameter Extensions for the Swedish OpenID Connect Profile - Version 1.1.
6. Changes between versions
Changes between version 1.0 and version 1.1:
Section 2.4, Signature Extension Support, was added. It defines the requirements for OpenID Provider support of the Signature Extension specified in Signature Extension for OpenID Connect - Version 1.1.
Section 4, Security Requirements, was added.