alex_dimov
12/09/2022, 8:47 AMchristoph
12/09/2022, 9:42 AMalex_dimov
12/09/2022, 12:08 PMalex_dimov
12/09/2022, 12:12 PMvisch
12/09/2022, 7:21 PMvisch
12/09/2022, 7:23 PMalex_dimov
12/09/2022, 8:24 PMchristoph
12/10/2022, 12:26 AMAlmost all of oauth flows can be handled by storing the refresh tokens.That is true. But the security problem is that for any OAuth 2.0 token flows that don't use a client secret (and Alex's example indicates such a Public client flow without a client secret!), the refresh token when stolen is the ONLY thing needed to take over the identity. The OAuth 2.0 Security Best Current Practice says on this topic:
2.2.2. Refresh Tokens
Refresh tokens for public clients MUST be sender-constrained or use refresh token rotation as described in Section 4.13.https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-refresh-tokens https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#refresh_token_protection https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-recommendations So, in short. I think that transferring and re-using refresh tokens from a public client flow (e.g. Authorization code grant flow) within a confidential client flow (e.g. Client Credentials flow) should be much more discouraged in the industry than it currently is.