Abstract

This specification defines security requirements for OAuth 2.0 Clients, Authorization Servers and Protected Resources participating in Federationskontext BAS. It establishes requirements for transport protection, client authentication, keys, signature algorithms and key rollover. The requirements extend, and are intended to be read together with, Federationskontext BAS: OAuth 2.0 Metadata Requirements and the Ena OAuth 2.0 Interoperability Profile.

1. Introduction

Federationskontext BAS, hereafter BAS, is a federation context for machine-to-machine access within, and towards, the Swedish public sector. Its Entities are OAuth 2.0 Clients, Authorization Servers and Protected Resources, whose metadata requirements are stated in [BAS.Metadata]. These Entities rely on signatures to authenticate each other and to protect access tokens. A common set of requirements is therefore needed for how transport security is applied, how Clients authenticate, which keys and signature algorithms are acceptable, and how keys are replaced without disrupting other parties.

This specification collects those requirements in one place. The requirements of Section 8 of [Ena.OAuth2], the profile that BAS applies, apply to every Entity in BAS. This specification restates those that concern keys and algorithms, states how they are interpreted within BAS, and adds the requirements that follow from operating in a federation, where the metadata of one Entity is consumed by many peers.

The requirements apply to protocol keys, published in the oauth_client, oauth_authorization_server or oauth_resource metadata of an Entity, see Section 5.1 of [OpenID.Federation.Connect]. They do not apply to Federation Entity Keys or to the signing of Entity Statements, for which Section 6 of [OIDC.Sweden.Federation] applies.

1.1. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.2. Terminology

This specification uses the terms "Entity", "Entity Configuration", "Federation Entity Key", "Trust Anchor" and "Resolved Metadata" as defined in [OpenID.Federation], and the terms "Client", "Authorization Server" and "Protected Resource" as defined in [Ena.OAuth2]. It uses the term "Federation Operator" as defined in [BAS.Metadata], and the term "Collaboration Context" (Swedish: samverkanskontext) as defined in [BAS.Rules]: a delimited collaboration within BAS in which the participating Entities agree to use a subset of what BAS permits.

2. General Security Requirements

All communication between Entities MUST be protected by TLS as stated in Section 8.1 of [Ena.OAuth2]. Entities MUST also conform to the applicable recommendations of [RFC9700].

private_key_jwt is the only client authentication method used within BAS. A Client MUST use it at the token endpoint, and at any revocation or introspection endpoint. An Authorization Server MUST NOT accept any other client authentication method from a Client in BAS.

Symmetric signature algorithms, and any mechanism based on a secret shared between two Entities, MUST NOT be used. Every signature in BAS can therefore be verified with a public key obtained through the signer's Resolved Metadata.

The Federation Operator enforces the client authentication method, and the algorithm values required by Section 3.1, through the Trust Anchor metadata policy stated in Section 7.1 of [BAS.Metadata]. Other requirements in this document are verified by the parties to an exchange.

3. Cryptographic Requirements

BAS does not require support for OpenID Connect Relying Party Metadata Choices 1.0. As Section 7 of [OIDC.Sweden.Federation] permits, the interoperability issues that specification addresses are instead handled by a single client authentication method, see Section 2, and a common set of signature algorithms that all Entities support for validation, see Section 3.1.

Protocol messages in BAS are protected by TLS and are not encrypted. No encryption algorithms are therefore mandatory, and no Entity is required to support encryption. This fulfils the requirement of Section 7 of [OIDC.Sweden.Federation] that federation rules cover encryption algorithms.

3.1. Signature Algorithms

Entities MUST meet the requirements on algorithms and key lengths of Section 8.2 of [Ena.OAuth2]. All Entities MUST support validation of signatures using RS256 and ES256 [RFC7518], as Section 8.2 of [Ena.OAuth2] requires. All Entities SHOULD also support validation of signatures using RS384, RS512, ES384 and ES512, so that the full set recommended by Section 7 of [OIDC.Sweden.Federation] is supported. That set is the one Section 6 of [OIDC.Sweden.Federation] requires for validation of Entity Statements. The requirements apply to validation only: an Entity that produces signatures MAY use a single algorithm and a single key type.

An Authorization Server's token_endpoint_auth_signing_alg_values_supported MUST contain RS256 and ES256, and SHOULD contain RS384, RS512, ES384 and ES512.

The algorithm none, the HS256, HS384 and HS512 algorithms, and any algorithm that relies on SHA-1, MUST NOT be used.

3.2. Collaboration Contexts

A Collaboration Context MAY restrict which of the algorithms permitted by Section 3.1 are used within it. It MUST NOT permit an algorithm that Section 3.1 prohibits, and MUST NOT remove the requirement to support validation of RS256 and ES256.

4. Key Rollover

An Entity MUST replace a key without disrupting its peers. To allow every peer to select the correct key during a rollover, each JWK in the JWK Set of an Entity MUST include a kid parameter [RFC7517], also when the JWK Set holds a single key, and the value MUST be unique within the JWK Set. Every signed object MUST include the kid of the signing key in its JOSE header. How often an Entity replaces its keys is stated in [BAS.Rules], as Section 2.1 of [OIDC.Sweden.Federation] recommends.

The following requirements apply to a planned key rollover.

  • An Entity MUST publish a new key before using it. The time between publication and first use MUST be at least as long as a peer may hold a cached copy of a JWK Set that does not contain the new key. For keys in jwks, this is the time until the exp of the last Entity Configuration published without the new key, see Section 3.1 of [OpenID.Federation]. For keys at jwks_uri, it is the cache lifetime of the JWK Set document.
  • An Entity that publishes its keys at jwks_uri SHOULD state the cache lifetime of the JWK Set document using HTTP caching headers, such as Cache-Control.
  • An Entity MUST keep the previous key in its JWK Set until every object signed with it has expired, and SHOULD remove it after that. For an Authorization Server, this is the longest remaining lifetime of the access tokens it has signed with that key.
  • An Entity that verifies signatures MUST be able to handle a JWK Set holding several keys, and MUST select the key by the kid in the signed object.
  • An Entity that receives a signed object with a kid it does not recognise SHOULD obtain the signer's JWK Set again before rejecting the object, by fetching the jwks_uri document or by resolving the signer's metadata anew. It SHOULD limit how often it does so for a given signer.

If a key is compromised, the Entity MUST remove it from its JWK Set immediately, without observing the time limits above. Peers may continue to accept the key until their cached copy of the JWK Set expires, which bounds the exposure.

5. Normative References

  • [BAS.Metadata] The Swedish Agency for Digital Government (Digg), "Federationskontext BAS: OAuth 2.0 Metadata Requirements 1.0, draft 02", 6 October 2026.
  • [BAS.Rules] The Swedish Agency for Digital Government (Digg), federation rules for Federationskontext BAS, in preparation.
  • [Ena.OAuth2] "Ena OAuth 2.0 Interoperability Profile", https://ena-infrastructure.github.io/specifications/ena-oauth2-profile.html.
  • [OIDC.Sweden.Federation] Lindström, M. and S. Santesson, "Swedish OpenID Federation Deployment and Interoperability Profile 1.0, draft 03", 2 October 2026, https://www.oidc.se/specifications/swedish-openid-federation-profile.html.
  • [OpenID.Federation] Hedberg, R., Jones, M. B., Ed., De Marco, G., Solberg, A. Å., Bradley, J., and V. Dzhuvinov, "OpenID Federation 1.1", 5 May 2026, https://openid.net/specs/openid-federation-1_1.html.
  • [OpenID.Federation.Connect] Hedberg, R., Jones, M. B., Ed., De Marco, G., Solberg, A. Å., Bradley, J., and V. Dzhuvinov, "OpenID Federation for OpenID Connect 1.1", 5 May 2026, https://openid.net/specs/openid-federation-connect-1_1.html.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015.
  • [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May 2015.
  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
  • [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, January 2025.
  • No labels