FAPI 2 vs. Security BCP Gap Analysis

[Daniel Fett]

I checked the latest version of FAPI 2 against the latest version (-29) of the Security BCP and noticed that there are some (minor?) discrepancies between the two. It may be fine to not change anything as they either affect corner-cases or are only recommendations in the BCP, but we should discuss how we want to proceed for each of them:

Access Token Privilege Restriction

Security BCP, Section 2.3: The privileges associated with an access token SHOULD be restricted to the minimum required for the particular application or use case. (...) In particular, access tokens SHOULD be audience-restricted to a specific resource server, or, if that is not feasible, to a small set of resource servers. (...) Additionally, access tokens SHOULD be restricted to certain resources and actions on resource servers or resources.

This is not currently implemented by FAPI 2.

Client IDs

Security BCP, Section 2.6: Under the conditions described in Section 4.15.1, authorization servers SHOULD NOT allow clients to influence their client_id or any claim that could cause confusion with a genuine resource owner.

This is not currently covered by FAPI 2.

TLS Requirements

Security BCP, Section 2.6: It is RECOMMENDED to use end-to-end TLS according to [BCP195] between the client and the resource server.

The use of TLS is covered by FAPI 2, but there is no explicit recommendation on it being used end-to-end.

Security BCP, Section 2.6: Authorization responses MUST NOT be transmitted over unencrypted network connections. To this end, authorization servers MUST NOT allow redirect URIs that use the http scheme except for native clients that use Loopback Interface Redirection as described in [RFC8252], Section 7.3.

This is not currently an explicit requirement in FAPI 2, but it is covered by the following statement in FAPI 2:

To protect against network attacks, clients, authorization servers, and resource servers (1.) shall only offer TLS protected endpoints and shall establish connections to other servers using TLS.

In-Browser Communication

Security BCP, Section 2.6: If the authorization response is sent with in-browser communication techniques like postMessage WHATWG.postmessage_api instead of HTTP redirects, both the initiator and receiver of the in-browser message MUST be strictly verified as described in Section 4.17.

The use of these techniques is not explicitly covered by FAPI 2.

Cross-Origin Resource Sharing

Security BCP, Section 2.6: To support browser-based clients, endpoints directly accessed by such clients including the Token Endpoint, Authorization Server Metadata Endpoint, jwks_uri Endpoint, and the Dynamic Client Registration Endpoint MAY support the use of Cross-Origin Resource Sharing (CORS, WHATWG.CORS). However, CORS MUST NOT be supported at the Authorization Endpoint, as the client does not access this endpoint directly; instead, the client redirects the user agent to it.

This is not currently covered by FAPI 2.

[Daniel Fett]

Discussed on the call:

• Access Token Privilege Restriction → discuss if applicable here
• Client IDs → requires a lot of context, mention in security considerations?
• TLS Requirements → might be easy to add
• In-Browser Communication → requires a lot of context, special use case, but might be worth mentioning (security considerations?)
• Cross-Origin Resource Sharing → out of scope?

‌

[Dave Tonge]

For the TLS one, I think this is enough?

To protect against network attacks, clients, authorization servers, and resource
servers

 1. shall only offer TLS protected endpoints and shall establish connections
    to other servers using TLS;

‌

[Dave Tonge]

also looking at the in-browser one, I’m not sure if we should address it. I think we need to stay out of particular software implementations (e.g. a client that is split into different components). So I think this is only valid for a response mode that supports postMessage, e.g. https://www.ietf.org/archive/id/draft-meyerzuselha-oauth-web-message-response-mode-00.html ?

Do we need to restrict the response_mode used? I’m not sure if we do anywhere?

[Dave Tonge]

we discussed on the call:

1. Not adding the end to end TLS clause as we can’t test and people will still use cloudflare, etc.
2. Adding in some text about the in browser communication, but for review in a PR, not sure there is consensus yet on adding it in.
3. we also talked about whether we should restrict response modes, with one view being we should restrict as currently if a server and client agree, they can use a completely unknown response mode and still be FAPI compliant, and another view being that we shouldn’t restrict this, as the current OAuth 2.0 response modes aren’t problematic for us and we don’t want to unnecessarily add restrictions in which will make it harder for FAPI 2.0 to be used if a new secure response mode is published

‌

[Nat Sakimura]

Most of the issues have been dealt with.

Response mode still needs to be addressed, but Dave believes it can be done with implementation advice.

We probably should close it on Aug 21 call if no objections by then.

[Dave Tonge]

No one on the Atlantic call today felt that we needed to add anything in with regards to response modes or in browser communication - so closing this ticket