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_sec
Hi,
You could perhaps use private_key_jwt from the OpenID specs:
https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
Yours,
Emelia
> On 3 Mar 2025, at 20:06, Srinivas Challa
> wrote:
>
> Hi,
> I am from Workday working on the OAuth feature. We currently support PKCE
>
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
tokens, but it is recommended that the AS issue one-time us
All,
The following is hopefully our final agenda for Bangkok:
https://datatracker.ietf.org/doc/agenda-122-oauth/
We have no more room to add new topics.
Please, take a look and let us know what you think.
Regards,
Rifaat & Hannes
___
OAuth mailing li
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 estab
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,
Srinivas,
I think what you're getting at is that you don't want to issue a refresh
token to an unauthenticated client, for example a browser client where you
can't protect the secret. As Aaron alluded, PKCE is like a state
param--it's never a bad idea.
Have you considered using DCR for the browse
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
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
a
