[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