5.1.1 Introduction

The OIDF FAPI security profile specifies security requirements for high risk API resources protected by the OAuth 2.0 Authorization Framework that consists of RFC 6749, RFC 6750, RFC 7636, and other specifications.

There are different levels of risks associated with access to these APIs. For example, read and write access to a bank API has a higher financial risk than read-only access. As such, the security profiles of the authorization framework protecting these APIs are also different.

This profile describes security provisions for the server and client that are appropriate for highly secured APIs by defining the measures to mitigate:

• attacks that leverage the weak binding of endpoints in RFC 6749 (e.g. malicious endpoint attacks, IdP mix-up attacks), and
• attacks that modify authorization requests and responses unprotected in RFC 6749.

This profile does not support public clients.

The following ways are specified to protect against modifications of authorization responses: Implementations can leverage OpenID Connect’s hybrid fow that returns an ID Token in the authorization response or they can utilize the JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) that returns and protects all authorization response parameters in a JWT.

5.1.2 ID Token as detached signature

While the name ID Token (as used in the OpenID Connect hybrid flow) suggests that it is something that provides the identity of the resource owner (subject), it is not necessarily so. While it does identify the authorization server by including the issuer identifier, it is perfectly fine to have an ephemeral subject identifier. In this case, the ID Token acts as a detached signature of the issuer to the authorization response and it was an explicit design decision of OpenID Connect Core to make the ID Token act as a detached signature.

This document leverages this fact and protects the authorization response by including the hash of all of the unprotected response parameters, e.g. code and state, in the ID Token.

While the hash of the code is defined in OIDC, the hash of the state is not defined. Thus this document defines it as follows.

s_hash

State hash value. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the state value, where the hash algorithm used is the hash algorithm used in the alg header parameter of the ID Token’s JOSE header. For instance, if the alg is HS512, hash the state value with SHA-512, then take the left-most 256 bits and base64url encode them. The s_hash value is a case sensitive string.

5.1.3 JWT secured authorization response mode for OAuth 2.0 (JARM)

An authorization server may protect authorization responses to clients using the “JWT Secured Authorization Response Mode” JARM.

JARM allows a client to request that an authorization server encodes the authorization response (of any response type) in a JWT. It is an alternative to utilizing ID Tokens as detached signatures for providing increased security on authorization responses and can be used with plain OAuth.

This specification facilitates use of JARM in conjunction with the response type code.

NOTE: JARM can be used to protect OpenID Connect authentication responses. In this case, the OpenID RP would use response type code, response mode jwt and scope openid. This means JARM protects the authentication response (instead of the ID Token) and the ID Token containing end-user claims is obtained from the token endpoint. This facilitates privacy since no end-user claims are sent through the front channel. It also provides decoupling of message protection and identity providing since a client (or RP) can basically use JARM to protect all authorization responses and turn on OpenID if needed (e.g. to log the user in).

5.2.1 Introduction

API resources may contain sensitive data and/or have increased security requirements. In order to fulfill different security needs, FAPI Security Profile 1.0 defines an advanced profile that is beyond the baseline security requirements defined in the Part 1: Baseline document.

As a profile of the OAuth 2.0 Authorization Framework, this document mandates the following for the advanced profile of the FAPI Security Profile 1.0.

5.2.2 Authorization server

5.2.3 Confidential client

6.2.1 Protected resources provisions

The protected resources supporting this document

1. shall support the provisions specified in clause 6.2.1 FAPI Security Profile 1.0 - Part 1: Baseline; and
2. shall adhere to the requirements in RFC 8705.

6.2.2 Client provisions

The client supporting this document shall support the provisions specified in clause 6.2.2 of FAPI Security Profile 1.0 - Part 1: Baseline.

8.3.1 Introduction

In RFC 6749 and RFC 6750, the endpoints that the authorization server offers are not tightly bound together. There is no notion of authorization server identifier (issuer identifier) and it is not indicated in the authorization response unless the client uses different redirection URI per authorization server. While it is assumed in the OAuth model, it is not explicitly spelled out and thus many clients use the same redirection URI for different authorization servers exposing an attack surface. Several attacks have been identified and the threats are explained in detail in RFC 6819.

8.3.2 Client credential and authorization code phishing at token endpoint

In this attack, the client developer is socially engineered into believing that the token endpoint has changed to the URL that is controlled by the attacker. As a result, the client sends the code and the client secret to the attacker, which the attacker can then replay.

When the FAPI Security Profile 1.0 client uses RFC 8705, the client’s secret (the private key corresponding to its TLS certificate) is not exposed to the attacker, which therefore cannot authenticate towards the token endpoint of the authorization server. However, there is still the potential for a phished code be injected into a different flow involving an honest client.

8.3.3 Identity provider (IdP) mix-up attack

In this attack, the client has registered multiple IdPs and one of them is a rogue IdP that returns the same client_id that belongs to one of the honest IdPs. When a user clicks on a malicious link or visits a compromised site, an authorization request is sent to the rogue IdP. The rogue IdP then redirects the client to the honest IdP that has the same client_id. If the user is already logged on at the honest IdP, then the authentication may be skipped and a code is generated and returned to the client. Since the client was interacting with the rogue IdP, the code is sent to the rogue IdP’s token endpoint. At the point, the attacker has a valid code that can be exchanged for an access token at the honest IdP. See OAUTHSEC for a detailed description of the attack.

This attack is mitigated by the use of OpenID Connect hybrid flow in which the honest IdP’s issuer identifier is included as the value of iss or JARM where the iss included in the response JWT. On receiving the authorization response, the client compares the iss value from the response with the issuer URL of the IdP it sent the authorization request to (the rogue IdP). The client detects the conflicting issuer values and aborts the transaction.

8.3.4 Access token phishing

Various mechanisms in this specification aim at preventing access token phishing, e.g., the requirement of exactly matching redirect URIs and the restriction on response types that do not return access tokens in the front channel. As a second layer of defense, FAPI Security Profile 1.0 advanced clients use RFC 8705 meaning the access token is bound to the client’s TLS certificate. Even if an access token is phished, it cannot be used by the attacker. An attacker could try to trick a client under his control to make use of the access token as described in FAPISEC (“Cuckoo’s Token Attack” and “Access Token Injection with ID Token Replay”), but these attacks additionally require a rogue authorization server or misconfigured token endpoint.

For the “Access Token Injection with ID Token Replay” attack, the attacker tricks a client under his control to start a normal authorization flow to obtain an authorization response with an ID Token. The ID Token is replayed along with a phished access token at the token endpoint (which is misconfigured in the client to point to an attacker-controlled URL). The attacker then gains access to resources of the honest resource owner through the client.

Misconfigured endpoints are mitigated by using metadata in the authorization server’s published metadata document as defined in OIDD or RFC 8414.

ID Token replay can be mitigated by requiring the at_hash in the token endpoint’s ID Token response to verify the validity of the access token.

8.4.1 Introduction

In RFC 6749 the authorization request and responses are not integrity protected. Thus, an attacker can modify them.

8.4.2 Authorization request parameter injection attack

In RFC 6749, the authorization request is sent as a query parameter. Although RFC 6749 mandates the use of TLS, the TLS is terminated in the browser and thus not protected within the browser; as a result an attacker can tamper the authorization request and insert any parameter values.

The use of a request object or request_uri in the authorization request will prevent tampering with the request parameters.

The IdP confusion attack reported in SoK: Single Sign-On Security – An Evaluation of OpenID Connect is an example of this kind of attack.

8.4.3 Authorization response parameter injection attack

This attack occurs when the victim and attacker use the same RP client. The attacker is somehow able to capture the authorization code and state from the victim’s authorization response and uses them in his own authorization response.

This can be mitigated by using OpenID Connect hybrid flow where the c_hash, at_hash, and s_hash can be used to verify the validity of the authorization code, access token, and state parameters. It can also be mitigated using JARM by verifying the integrity of the authorization response JWT.

The server can verify that the state is the same as what was stored in the browser session at the time of the authorization request.

8.6.1 Encryption algorithm considerations

For JWE, both clients and authorization servers

1. shall not use the RSA1_5 algorithm.

10.1.1. Registry contents

• Claim name: s_hash
• Claim Description: State hash value
• Change Controller: OpenID Foundation FAPI Working Group - openid-specs-fapi@lists.openid.net
• Reference: Section 5 of [[ this document ]]