Authentication property of FAPI 2.0

[Nat Sakimura]

this is a continuation of the email discussion in the thread: https://lists.openid.net/pipermail/openid-specs-fapi/2023-July/002931.html

‌

It is wrt the authentication property of FAPI 2.0 (and FAPI 1.0 flows that does not use OpenID Connect) described on the FAPI 2.0 attacker model. 

I quote: 

2.2. Authentication

The FAPI 2.0 Security Profile aims to ensure that no attacker is able to log in at a client under the identity of another user.

The ID token is the credential for authentication in OpenID Connect. This security goal therefore is fulfilled if no attacker can obtain and use an ID token identifying another user for login.

The case in question is as follows. 
User A has accounts A1 and A2 at the authorisation server/resource server. User A has an account C_A1 at the client that stores historical transaction information from A1. When User A was prompted by the client to refresh the access to A1 when they logged in to the client, they got redirected to the authorisation server and, by mistake, used A2 to authorise. The new access token is bound to A2 instead of A1. By using it, C_A1 gets the transaction information from A2 and connects them to the previously obtained data from A1. This is not correct behaviour. How is this mitigated in FAPI 2.0 and FAPI 1.0 with JARM? 
A similar situation occurs when users A and B share a browser, and the authorisation server is maintaining a long-run session.

It probably needs to be addressed either with a stable identifier in the functional API or at the authentication protocol level. 

So, the security goal may be: 

1. When session correlations are sought, then responses from a different account shall be detected. 
2. When session correlations (linking) are to be avoided, then the receiver should not be able to identify whether the session belongs to the same user with a significantly greater probability than 1/2. 

‌

[Daniel Fett]

Just as a general thought, I see this more as a functional property rather than a security property (that nonetheless could be addressed, and maybe should). In the first scenario described, the client gets confused about which account is connected, but the user is still secure. In the second scenario, user B effectively gets access to user A’s account (not depending on any FAPI or OAuth specifics) on the AS - sharing credentials is outside of what OAuth/FAPI tries to protect against.

The authentication property is defined the way it is to reflect what has been analyzed in the formal analyses.

[Nat Sakimura]

Write it in the Introduction and scope. Also in security considerations that identity management layer is out of scope for FAPI 2.0.

e.g. Identity management is out of the scope of this document. It is important to …

[Daniel Fett]

See https://bitbucket.org/openid/fapi/pull-requests/435

[Nat Sakimura]

The security analysis assumes that FAPI 2 is used with OpenID Connect so that ID Token is there. That’s why this attack did not surface as a problem.

[Nat Sakimura]

PR 435 is working on the attacker model.

In addition, in one of the previous calls, we agreed to add warnings in the security profile as well, perhaps in the introduction/scope and security consideration.

[Dave Tonge]

From Tim: However, the analysis also considers the case of an end user not being logged in at all at a client, but still granting that client access to the user’s resources. In the latter case, the client identifies the user (agent) by a cookie (that cookie is not bound to an identity, only to an authorization grant flow). I.e., the analysis does consider using FAPI 2.0 with and without OIDC.

[Dave Tonge]

we discussed that perhaps we don’t need anything on the main security profile as we have it in the attacker model

[Dave Tonge]

PR was merged into the attacker model

[Nat Sakimura]

I am opening another issue as we also agreed to add some text to the security profile’s introduction or scope in relation to it since many readers will not read the attacker model.