[Openid-specs-fapi] Issue #212: FAPI-CIBA; should id_token tie itself to the auth request? (openid/fapi)
Joseph Heenan
issues-reply at bitbucket.org
Sat Jan 26 20:16:30 UTC 2019
New issue 212: FAPI-CIBA; should id_token tie itself to the auth request?
https://bitbucket.org/openid/fapi/issues/212/fapi-ciba-should-id_token-tie-itself-to
Joseph Heenan:
Currently CIBA doesn't tie the issued id_token back to the original authorisation request in anyway; e.g. here is the id_token body from the spec example:
```
#!json
{
"iss": "https://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"email": "janedoe at example.com",
"exp": 1537819803,
"iat": 1537819503
}
```
Arguably you don't need to tie the id_token back to anything, because the operation was done entirely in the back channel, and the token endpoint is told which auth_req_id is being requested.
It does feel a little bit odd to me, and perhaps with the higher security environment FAPI targets we should include the client_notification_token (or something else) that lets the client verify the id_token does correspond to it's original request.
The only attack I can really see is plausible would involve a mitm between the RP & OP and requires the RP to be lax in TLS certificate validation or the attacker to obtain a valid certificate, and even then the attacker can only switch out one valid id_token for a different one. (I guess a compromise between the OP's TLS gateway and the AS is also a possible attack vector.)
The question is probably similar to those posed in #200 and #117; as I think we're going with a bit of paranoia in both cases I'd probably veer towards thinking we should be paranoid in this case too.
More information about the Openid-specs-fapi
mailing list