Thanks Thumilan, Looks like the recommendation PKCE + Sender constrained tokens for public clients is the right solution. Just wanted to make sure with the working group you see public clients are willing to uptake DPoP or mTLS (not sure how this works for mobile clients as it requires pre established trust) and adoptions will not be an issue if enforced/required.
Thanks, -Srinivas From: Thumilan <thumilan.conn...@gmail.com> Date: Tuesday, March 4, 2025 at 8:48 AM To: Srinivas Challa <srinivas.cha...@workday.com> Cc: Aaron Parecki <aa...@parecki.com>, oauth@ietf.org <oauth@ietf.org> Subject: Re: [OAUTH-WG] Re: Regarding issuing refresh tokens for PKCE based OAuth grant flow Hi Srinivas, Using PKCE enhances security for public clients when acquiring tokens via authorization code grants. Regarding your question about using a refresh token (RT) to obtain an access token (AT), I believe you're asking about securing Hi Srinivas, Using PKCE enhances security for public clients when acquiring tokens via authorization code grants. Regarding your question about using a refresh token (RT) to obtain an access token (AT), I believe you're asking about securing the token endpoint for public clients. To address this, I recommend implementing token binding mechanisms such as DPoP (Demonstrating Proof of Possession) or mTLS (Mutual TLS) to ensure secure token usage and mitigate risks along with one time refresh tokens. Thanks, Thumilan On Tue, 4 Mar 2025, 22:06 Srinivas Challa, <srinivas.challa=40workday....@dmarc.ietf.org<mailto:40workday....@dmarc.ietf.org>> wrote: Hi, Thanks for the responses. I agree on the recommendation that all clients should use PKCE. Let me clarify the question is about public clients that cannot have a client_secret getting refresh tokens without providing client credentials. Based on the response, looks like as long as we use one time use RT, it is fine. I would like to enforce sender constrained tokens for additional safety, but not sure if clients are willing to support it. So wanted to confirm if there is any discussion about doing something like device_secret for native app SSO to provide client credentials to public clients along with refresh token. Thanks, -Srinivas From: Aaron Parecki <aaron=40parecki....@dmarc.ietf.org<mailto:40parecki....@dmarc.ietf.org>> Date: Tuesday, March 4, 2025 at 8:04 AM To: Srinivas Challa <srinivas.cha...@workday.com<mailto:srinivas.cha...@workday.com>> Cc: oauth@ietf.org<mailto:oauth@ietf.org> <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Regarding issuing refresh tokens for PKCE based OAuth grant flow Hi Srinivas, There is no connection between PKCE and refresh tokens. All OAuth clients should be using PKCE. https: //www. rfc-editor. org/rfc/rfc9700. html#section-2. 1. 1 If a client doesn't have client credentials, it can still use refresh Hi Srinivas, There is no connection between PKCE and refresh tokens. All OAuth clients should be using PKCE. https://www.rfc-editor.org/rfc/rfc9700.html#section-2.1.1<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9700.html*section-2.1.1__;Iw!!Iz9xO38YGHZK!-TjZd1Zv20Hi16CDE3Hytu91gSM4ZY_OFJOtnJhRgM0b-ZF0OmhKoLWVzypxL5udf7i_0T8YMMSFLZDU8pOGnisFZEu6yp5l2fqYWw$> If a client doesn't have client credentials, it can still use refresh tokens, but it is recommended that the AS issue one-time use refresh tokens. https://www.rfc-editor.org/rfc/rfc9700.html#section-2.2.2<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9700.html*section-2.2.2__;Iw!!Iz9xO38YGHZK!-TjZd1Zv20Hi16CDE3Hytu91gSM4ZY_OFJOtnJhRgM0b-ZF0OmhKoLWVzypxL5udf7i_0T8YMMSFLZDU8pOGnisFZEu6yp74ptnCOA$> Aaron On Tue, Mar 4, 2025 at 5:06 AM Srinivas Challa <srinivas.challa=40workday....@dmarc.ietf.org<mailto:40workday....@dmarc.ietf.org>> wrote: Hi, I am from Workday working on the OAuth feature. We currently support PKCE based OAuth flow, but we currently do not support returning refresh token since client authentication is not possible without client_secret to exchange RT for AT for offline access. I do see pattern of using device_secret as part of OpenId Native SSO specification<https://urldefense.com/v3/__https:/openid.net/specs/openid-connect-native-sso-1_0-04.html__;!!Iz9xO38YGHZK!-TjZd1Zv20Hi16CDE3Hytu91gSM4ZY_OFJOtnJhRgM0b-ZF0OmhKoLWVzypxL5udf7i_0T8YMMSFLZDU8pOGnisFZEu6yp7jn09xfg$> but not sure if this is the right pattern. Is there a recommendation on the security best practice/pattern on how we can support RT for PKCE based flows? Thanks, -Srinivas _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org> _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
