DPoP does not require pre-established trust, the client creates its own key and the AS binds the tokens to the key when it's first seen. Future uses of the tokens rely on presenting proof of the same key, which is where the sender-constraining comes in. DPoP can be used by both JavaScript clients as well as mobile clients.
Also please note Thumilan that PKCE is not just for public clients, it also protects confidential clients from certain attacks as well. This is described in Section 4.5 of RFC9700 https://www.rfc-editor.org/rfc/rfc9700.html#section-4.5 Aaron On Tue, Mar 4, 2025 at 9:07 AM Srinivas Challa <srinivas.cha...@workday.com> wrote: > 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> 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> > *Date: *Tuesday, March 4, 2025 at 8:04 AM > *To: *Srinivas Challa <srinivas.cha...@workday.com> > *Cc: *oauth@ietf.org <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> 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 > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
