Financial-grade API Security Profile 1.0 - Part 1: Baseline

[maennchen]

Spec: https://openid.net/specs/openid-financial-api-part-1-1_0.html

Work Required

• Support mTLS (>= 1.2)
• Add configuration that restricts the client to more safe settings
  • Require nonce or state depending on openid scope
  • Public Client: require PKCE
  • Store redirect_uri in session and compare on redirect back
  • Require CSRF
  • Compare scopes (no additional ones compared to requested scopes)
  • Confidential Client: RSA >= 2048, EC >= 160, Symmetric Key >= 128
  • No params in query, only request body / request jwt
  • Set Date header on requests
  • Set x-fapi-interaction-id header
  • Put x-fapi-interaction-id value into telemetry events
  • Set x-fapi-customer-ip-address header
  • Set x-fapi-auth-date header

📌 This issue is here to track interest for the implementation. Upvote if you would like this implemented.

[dustinfarris]

Storing redirect_uri with a lot of query parameters in session can bump against the cookie size limit depending on the browser.

[maennchen]

@dustinfarris This does not seem to be related to this specific discussion.

I‘m assuming that you‘re having issues with Oidcc.Plug.Authorize, is that correct?

Do you mind opening an issue in the oidcc_plug respository?

[dustinfarris]

@dustinfarris This does not seem to be related to this specific discussion.

I‘m assuming that you‘re having issues with Oidcc.Plug.Authorize, is that correct?

Hi, this was in reference to this discussion, specifically this goal:

Store redirect_uri in session and compare on redirect back

We have found that very long URIs (e.g. with many query params) can go beyond the limitations browsers place on cookie size when attempting to store them in the session, triggering errors. We are, instead, storing the redirect_uri in the state along with a CSRF token, which has been working well so far.

[maennchen]

@dustinfarris Oh, sorry for hiding it then.

I however don’t fully understand. This standard hasn’t been implemented yet.

Are you already facing issues or is this a theoretical issue when implementing this?

If and when we implement this specification, we can see if it’s possible to store a hash of it (should be fairly snall) or if we need the full URL for the comparison. (Not sure without reading the spec right now if it’s an exact match or if you need to do a smarter comparison.)

If we need the full URL, a session implementation that allows longer contents would be required. With plug for example, you can use different strategies and store the session contents in ETS or a DB. In that case only the session ID is saved in the cookie.