[Openid-specs-fapi] Issue #523: Rotation of Refresh token - Compromised client highlighted by AU - CDR Independent review. (openid/fapi)

[Anoop Saxena]

New issue 523: Rotation of Refresh token - Compromised client highlighted by AU - CDR Independent review.
https://bitbucket.org/openid/fapi/issues/523/rotation-of-refresh-token-compromised

Anoop Saxena:

Team,

I think we have reviewed this topic in the past - “Rotation of Refresh token”.  \( [https://bitbucket.org/openid/fapi/issues/456/proposal-should-we-remove-support-for](https://bitbucket.org/openid/fapi/issues/456/proposal-should-we-remove-support-for)\) and landed on decision not support refresh token rotation - [https://bitbucket.org/openid/fapi/pull-requests/306/add-refresh-token-rotation-clause-and-note](https://bitbucket.org/openid/fapi/pull-requests/306/add-refresh-token-rotation-clause-and-note) 

‌

There is a independent analysis done in AU CDR and report is shared [https://github.com/ConsumerDataStandardsAustralia/standards/issues/258](https://github.com/ConsumerDataStandardsAustralia/standards/issues/258) . In the report, see 7.2 & 7.3 on “Token Rotation”  on page 36, 37 and 38. 

Few call-outs:

1. CONCERN

    1. Replay attacks remains in the case of client being compromised 
    2. Longer window of upto 12 month life of refresh token is risk.  
    
2. CONSIDERATION

    1. Consider overlap of new and old for while to minimized until new one is used. 
    2. Suggestion for further discussion 26. Recommend that FAPI re-evaluates  
      the security implications of not performing refresh token rotation if a con
dential client is compromised.
    3. Recommendation 27. If no changes are forthcoming to FAPI, the Data Standards should be consistent with it and only discourage but not prohibit token rotation
    

‌

Purpose of this ticket to address these concerns and evaluate consideration working with WU CDR team. 

‌

‌

‌