Background

There has been some discussion / questioning of the time limit placed on Security Profile Authentication Requests of 60 minutes as defined by FAPI and FAPI-CIBA.

A concern raised was that use-cases where consent authorisation might be initiated and held open for long periods, such as 30 days for invoicing, are not supported. This however, is not an issue of consent approval (which is initiated with the Authentication Request), but more how should future dated activity such as payments or payment requests be made visible to customers. The latter might be needed prior to requesting payment approval, or making payments on a date later than today. Neither strictly requires a change to Authentication Request time limit.

Authentication Requests in the Security Profile are limited in lifetime to 60 minutes. The following is an explanation on the impacts of longer lifetimes, and why shorter lifetimes is generally preferred.

Authentication Requests and Consent authorisation steps

The basic steps involved in consent authorisation are:

1. Third Party and Customer agree consent

2. Third Party creates a consent resource, not associated with any customer at this point

3. Third Party initiates consent approval, using an Authentication Request (both redirect and decoupled) sent to the API Provider

   • this Authentication Request associates the consent and customer, and also requests the customer make a yes/no decision

4. Customer is redirected or is informed of consents pending. Customer authenticates, reviews and approves consent (or rejects).

   • One interpretation of decoupled is that customers must navigate to API provider by themselves, rather than being notified

5. Third Party is notified of result and retrieves tokens

6. Third Party uses consent to request data or perform action

The time between 3 and 4 is the timeframe under discussion.

FAPI references

In both FAPI CIBA and FAPI 1.0 Final the lifetime of an Authentication Request token is restricted (by setting exp - nbf <= 3600) to 60 minutes or less.

Threat model

Interception / compromise sensitive information

The longer a request is valid for, the more time is available to analyse, reuse or manipulate the sensitive material contained. It is desirable to reduce the window to as short as practically possible to reduce the time that sensitive material is exposed.

Replay attacks

Authentication Requests could (in theory) be sniffed during transmission, and may be used in replay attacks, where the attacker replays either modified or unmodified tokens. Incorrect JWT handling practices by the Authorization Server can lead to processing requests more than once, or authorisation of consents that were not intended.

Authorization server attacks

The longer Authentication Requests are valid (and not expired) creates a risk for the Authorization Server. This can take the form of information exposure, increased server load or memory exhaustion/leaks.

Shorter validity reduces the potential overlap and multiple in-flight requests for customer, causing confusion or possibly mix-up of approvals (approving one consent when another was intended).

Client in unknown state for extended period

A client has submitted the Authentication Request with the intent of receiving a decision (consent authorisation). The longer this is left undetermined, the longer a client must maintain interim state and cannot complete any processing that relied on the decision. This creates a logic risk that could result in compromise or undesirable user experience. Additionally, in a polling situation, the client will continue to request the final state and access tokens for a protracted period, potentially opening up the compromise of the access token when issued.

PSD2 requirement

PSD2 has a non-specific requirement for authorisation to occur in the shortest practical time. This has had an influence on the decision to keep the validity time for Authentication Requests short for FAPI.

FAPI attacker model

The FAPI attacker model was formalised for FAPI 2.0, where previously it was principles based^[1]. Nevertheless, the considerations are similar; browsers, mobile operating systems and networks are considered potentially compromised, with the subsequent requirements in security profiles designed to mitigate these to the extent possible.

The FAPI 2.0 attacker model is described here.

1. What are the differences between FAPI 1.0 and FAPI 2.0 and what do they mean to you? - OpenID Foundation ↩︎