[Openid-specs-fapi] Authentication property of FAPI 2.0
Nat Sakimura
nat at nat.consulting
Sun Jul 23 22:32:05 UTC 2023
Hi
I have a question about 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.
<https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#section-2.2>
Authentication
<https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#name-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.*
<https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#section-2.2-1>
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.
<https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#section-2.2-2>
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.
Best regards,
Nat Sakimura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20230724/5b869019/attachment.html>
More information about the Openid-specs-fapi
mailing list