1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

FAPI-CIBA; should id_token tie itself to the auth request?

Issue #212 open
Joseph Heenan created an issue

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:

{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "email": "janedoe@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.

Comments (23)

  1. Joseph Heenan reporter

    I'm specifically thinking about id_tokens issued from the token endpoint; for the case where the id_token is received via push there's already a requirement to include a urn:openid:params:jwt:claim:auth_req_id claim in the returned id_token.

  2. Dave Tonge

    So I think that we have to assume there is no MITM between at the back channel endpoints. If there is then essentially everything is broken and just including the auth_req_id won't really improve things. Having said that, the reason we added auth_req_id and at_hash to the id token in push mode was because of this type of attack the other way round. The rationale for having it only in push mode is that sending tokens to an endpoint hosted by the RP is new to OAuth and there is potentially more chance of compromise for that mode.

    I think that in many scenarios there is likely to be a correlation to the hint supplied in the authentication request and some of the claims in the id token. For example in an open banking context it could be that the intent id is provided as part of a login_hint_token and this intent_id may be returned in the subject claim of the id_token. Perhaps that is enough?

  3. Joseph Heenan reporter

    I guess the other argument is that it's a potential mitigation against a server returning an id_token from a different session through error, perhaps allowing the client to detect the error, or a bad reuse of an auth_req_id. I guess that sadly it's a little common to see systems deployed that have TLS certificate checks disabled through carelessness when people use dev environments that have self-signed certificates. The MITM attack is possibly more likely if anyone ever uses a mobile app as a CIBA client.

    I think (as you say) correlating intent_id's would be sufficient in the OB case.

    Should we address it somehow in the FAPI-CIBA spec though?

  4. Freddi Gyara

    Does OIDC provide for this if the id_token was issued at the end of an auth code grant ? I don't really see this issued off the token endpoint any different ?

  5. Joseph Heenan reporter

    @fgyara in the hybrid flow, the client can use s_hash and nonce to tie the id_token back to the original request/session.

  6. Dave Tonge

    So I definitely think we need to properly document the attacker model. Correct me if I'm wrong but I believe the issue is linking the auth request to a signed assertion in the token response.

    In FAPI RW if nonce is used then this is achieved. However nonce is not required for FAPI RW unless there is a public client. Therefore I think we should close this issue.

    If we decide that this is an issue then we should apply it to FAPI RW as well.

  8. Joseph Heenan reporter

    @dgtonge FAPI-R requires that confidential clients use a nonce (they inherit from the public client requirements); I can't see anything in FAPI-RW that removes that requirement?

  10. Joseph Heenan reporter

    @dgtonge In JARM 'state' is included in the signed response, so the potential to substitute a different response and have it accepted is pretty low.

  12. Joseph Heenan reporter

    Whoops. Good point. So the JARM token endpoint response doesn't include any signed response, yes.

    So we've three different situations for the token endpoint I believe:

    1) FAPI-RW (non-JARM): returns a signed id_token that's bound to the original request by nonce

    2) FAPI-CIBA ping/poll: returns a signed id_token that's not bound to the original request

    3) FAPI-RW+JARM: I'm a little unclear on the JARM spec, but FAPI-RW+JARM seems to require signed id_tokens are still returned form the token endpoint so in that case the response is still bound to once as per '1'?

    I don't know what to conclude from this. It might be a good one to consider at the security workshop face to face?

  13. Dave Tonge

    If JARM is used to secure the authorization responses, the clauses 2, 3, and 4 of section 5.2.2. do not apply. For example, clients may use JARM in conjunction with the response type code.

    I think FAPI-RW with JARM doesn't require an id token to be returned from the token endpoint.

    However I think you make a good point that the nonce ties auth request, auth response and token response all together in the generic FAPI RW.

    I agree that this would be good to discuss at the security workshop

  14. Joseph Heenan reporter

    I think FAPI-RW with JARM doesn't require an id token to be returned from the token endpoint.

    I thought that was meant to be the case, but it's not what's actually in https://openid.net/specs/openid-financial-api-part-2-ID2.html - 5.2.2-8 requires the AS support signed id_tokens and public/confidential clients "shall require JWS signed ID Token be returned from endpoints;"; neither clause are called out as ones to ignore in "5.2.5. JWT Secured Authorization Response Mode"

  15. Dave Tonge

    Perhaps when OAuth Signed Request lands we should re-evaulate FAPI RW and check that it can be used without OIDC - that is the intention.

  16. Joseph Heenan reporter

    Yes; that'd make sense. It may be that a bit of restructuring of the document is necessary to make OIDC-vs-non-OIDC clearer, though I'm not entirely clear how we could do that whilst also following our goal of maintaining the numbering of the clauses between versions of the spec.

  17. Joseph Heenan reporter

    Interestingly I need to at least partially retract at least one of my previous statements - it turns out the OpenID Connect doesn't actually require the client to validate the signature on the id_token if it's received on the backchannel:

    If the ID Token is received via direct communication between the Client and the Token Endpoint [...], the TLS server validation MAY be used to validate the issuer in place of checking the token signature.

  24. Log in to comment
Assignee
Type
bug
Priority
major
Status
open
Component
CIBA
Milestone
2nd Implementers Draft
Votes
0
Watchers
5
Jira: the preferred issue tracker for Bitbucket. Join the team!