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.
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.
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.
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.
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.
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.
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.
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.
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.
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.