FAPI 2.0 Security Profile

5.1.1. Profiling this specification

This specification is a general purpose high security profile of OAuth 2.0 that has been proved by formal analysis to meet the stated attacker model.¶

This specification, and the underlying specifications, leave a number of choices open to implementors, deployers and/or ecosystems - with knowledge of the exact use cases, further reducing the number of choices may further improve security, or make implementation or interoperability easier.¶

However, for a profile to be compliant with this specification, the profile shall not remove or override mandatory behaviours - as doing so is likely to invalidate the formal security analysis and reduce security in potentially unpredictable ways.¶

5.2.1. Requirements for all endpoints

TLS connections shall be protected against network attackers. To this end, clients, authorization servers, and resource servers:¶

1. shall only offer TLS protected endpoints and shall establish connections to other servers using TLS. TLS connections shall be set up to use TLS version 1.2 or later.¶

2. when using TLS 1.2, follow the recommendations for Secure Use of Transport Layer Security in [RFC7525].¶

3. should use DNSSEC to protect against DNS spoofing attacks that can lead to the issuance of rogue domain-validated TLS certificates.¶

4. shall perform a TLS server certificate check, as per [RFC6125].¶

NOTE: Even if an endpoint uses only organization validated (OV) or extended validation (EV) TLS certificates, rogue domain-validated certificates can be used to impersonate the endpoints and conduct man-in-the-middle attacks. CAA records [RFC8659] can help to mitigate this risk.¶

5.2.2. Requirements for endpoints not used by web browsers

1. when using TLS 1.2, the server shall only permit the cipher suites listed in Section 5.2.2.1¶

2. when using TLS 1.2, the client should only permit the cipher suites listed in Section 5.2.2.1¶

3. When using the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 or TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 cipher suites, key lengths of at least 2048 bits are required.¶

5.2.3. Requirements for endpoints used by web browsers

Endpoints for the use by web browsers¶

1. shall use methods to ensure that connections cannot be downgraded using TLS Stripping attacks. A preloaded [preload] HTTP Strict Transport Security policy [RFC6797] can be used for this purpose. Some top-level domains, like .bank and .insurance, have set such a policy and therefore protect all second-level domains below them.¶

2. when using TLS 1.2, shall only use cipher suites allowed in [RFC7525]¶

5.3.1. Requirements for Authorization Servers

5.3.2. Requirements for Clients

5.3.3. Requirements for Resource Servers

The FAPI 2.0 endpoints are OAuth 2.0 protected resource endpoints that return protected information for the resource owner associated with the submitted access token.¶

Resource servers with the FAPI endpoints¶

1. shall accept access tokens in the HTTP header as in Section 2.1 of OAuth 2.0 Bearer Token Usage [RFC6750]¶

2. shall not accept access tokens in the query parameters stated in Section 2.3 of OAuth 2.0 Bearer Token Usage [RFC6750]¶

3. shall verify the validity, integrity, expiration and revocation status of access tokens¶

4. shall verify that the authorization represented by the access token is sufficient for the requested resource access and otherwise return errors as in section 3.1 of [RFC6750]¶

5. shall support and verify sender-constrained access tokens using one of the following methods:¶

   • MTLS as described in [RFC8705]¶

   • DPoP as described in [I-D.ietf-oauth-dpop]¶

5.6.1. Access token lifetimes

The use of short lived access tokens (combined with refresh tokens) potentially reduces the time window for some attacks.¶

The use of refresh tokens also allows clients to rotate their sender-constraining keys without loss of grants, either because of compromise of the key or as part of good security hygiene.¶

If issuing long-lived grants (e.g. days/weeks), the use of short lived (e.g. minutes/hours) access tokens combined with refresh tokens should be considered.¶

There is a performance and resiliency trade off, setting the access token life time too short can increase the load on and dependency on the authorization server.¶

5.6.2. DPoP Proof Replay

An attacker of type A7 (see [attackermodel]) may be able to obtain DPoP proofs that they can then replay.¶

This may also allow reuse of the DPoP proof with an altered request, as DPoP does not sign the body of HTTP requests nor most headers. For example, for a payment request the attacker might be able to specify a different amount or destination account.¶

Possible mitigations for this are:¶

1. Resource servers uses short-lived DPoP nonces to reduce the time window where a request can be replayed¶

2. Resource servers implement replay prevention using the jti header as explained in [I-D.ietf-oauth-dpop]¶

3. Replay of an altered request can be prevented by using signed resource requests as per FAPI Message Signing¶

4. Consider MTLS sender-constraining instead of DPoP¶

These mitigations may have potential complexity, performance or scalability tradeoffs. Attacker type A7 represents a powerful attacker and mitigations may not be necessary for many ecosystems.¶

5.6.3. JWKS URIs

This profile supports the use of private_key_jwt and in addition allows the use of OpenID Connect. When these are used Clients and Authorization Servers need to verify payloads with keys from another party. For Authorization Servers this profile strongly recommends the use of JWKS URI endpoints to distribute public keys. For Client's key management this profile recommends either the use of JWKS URI endpoints or the use of the jwks parameter in combination with [RFC7591] and [RFC7592].¶

The definition of the Authorization Server jwks_uri can be found in [RFC8414], while the definition of the Client jwks_uri can be found in [RFC7591].¶

In addition, this profile¶

1. requires that jwks_uri endpoints shall be served over TLS;¶

2. recommends that JOSE headers for x5u and jku should not be used; and¶

3. recommends that the JWK set does not contain multiple keys with the same kid.¶

5.6.4. Duplicate Key Identifiers

JWK sets should not contain multiple keys with the same kid. However, to increase interoperability when there are multiple keys with the same kid, the verifier shall consider other JWK attributes, such as kty, use, alg, etc., when selecting the verification key for the particular JWS message. For example, the following algorithm could be used in selecting which key to use to verify a message signature:¶

1. find keys with a kid that matches the kid in the JOSE header;¶

2. if a single key is found, use that key;¶

3. if multiple keys are found, then the verifier should iterate through the keys until a key is found that has a matching alg, use, kty, or crv that corresponds to the message being verified.¶

5.6.5. Injection of stolen access tokens

There are potential situations where the attacker may be able to inject stolen access tokens into a client to bypass [RFC8705] or [I-D.ietf-oauth-dpop] sender-constraining of the access token, as described in "Cuckoo's Token Attack" in [FAPI1SEC].¶

A pre-condition for this attack is that the attacker has control of an authorization server that is trusted by the client to issue access tokens for the target resource server. An attacker may obtain control of an authorization server by:¶

1. Compromising the security of a different authorization server that the client trusts, or¶

2. Acting as an authorization server and establishing a trust relationship with a client using social engineering, or by¶

3. compromising the client¶

The attack may be easier if a centralized directory or other resource server discovery mechanism allows the attacker to cause the client to send the stolen access token received from the attacker controlled Authorization Server to an honest Resource Server.¶

The pre-conditions for this attack do not apply to many ecosystems and require a powerful attacker. In situations where the pre-conditions may be met, the possible mitigations include:¶

1. Clients using different DPoP keys or MTLS certificates at each authorization server¶

2. Clients sending the issuer identifier the access token was obtained from to the resource server, and requiring resource servers to verify the issuer matches the authorization server that originally issued the token (though there is no standardized method for clients to send the issuer to the resource server)¶

3. Reducing the time window for the attack by using short lived access tokens alongside refresh tokens¶

5.6.6. Authorization Request Leaks lead to CSRF

An attacker of type A3a (see [attackermodel]) can intercept an authorization request, log in at the Authorization Server, receive an authorization code and redirect the honest user via a CSRF attack to the honest client but with the attacker's authorization code. This results in the user accessing the attackers resources, thus breaking session integrity.¶

It is important to note that all practically used redirect-based flows are susceptible to this attack, as redirection does not allow for a tight coupling of the session between the user's browser and the client on the one side and the session between the user's browser and the authorization server on the other side. This attack, however, requires a strong attacker who can read authorization requests and perform a CSRF attack in a short time window.¶

Possible mitigations for this are:¶

1. Requiring the Authorization Server to only accept a request_uri once. This will prevent attacks where the attacker was able to read the authorization request, but not use the request_uri before the honest user does so.¶

2. Requiring the Client to only make one authorization code grant call for each authorization endpoint call. This will prevent attacks where the attacker was unable to send the authorization response before the honest user does so.¶

3. Reducing the lifetime of the authorization code - this will reduce the window in which the CSRF attack has to be performed.¶

An attacker that has the option to block a user's request completely can circumvent the first and second defenses. In practice, however, attackers can often read an authorization request (e.g., from a log file or via some other side-channel), but not block the request from being sent. If the victim's internet connection is slow, this might increase the attacker's chances.¶

5.6.7. Browser-Swapping Attacks

An attacker that has access to the authorization response sent through a victim's browser can perform a browser-swapping attack as follows:¶

1. The attacker starts a new flow using their own browser and some client. The client sends a pushed authorization request to the authorization server and receives a request_uri in the response. The client then redirects the attacker's browser to the authorization server.¶

2. The attacker intercepts this redirection and forwards the URL to a victim. For example, the attacker can embed a link to this URL in a phishing website, an email, or a QR code.¶

3. The victim may be tricked into believing that an authentication/authorization is legitimately required. The victim therefore authenticates at the authorization server and may grant the client access to their data.¶

4. The attacker can now intercept the authorization response in the victim's browser and forward it to the client using their own browser.¶

5. The client will recognize that the authorization response belongs to the same browser that initially started the transaction (the attacker's browser) and exchange the authorization code for an access token and/or obtain user information.¶

6. Via the client, the attacker now has access to the user's resources or is logged in as the user.¶

With currently deployed technology, there is no way to completely prevent this attack if the authorization response leaks to an attacker in any redirect-based protocol. It is therefore important to keep the authorization response confidential. The requirements in this security profile are designed to achieve that, e.g., by disallowing open redirectors and requiring that the redirect_uri is sent via an authenticated and encrypted channel, the pushed authorization request, ensuring that the redirect_uri cannot be manipulated by the attacker.¶

Implementers need to consider the confidentiality of the authorization response critical when designing their systems, in particular when this security profile is used in other contexts, e.g., mobile applications.¶