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 browser based client? In this case, a locally created private key only identifies that one browser session--so the blast radius of leakage is minimal. Once you have a properly registered client, then you could use private_key_jwt client authn at the token endpoint as Emelia suggests. You could include an SSA in the browser based application (presented during DCR) to identify the scopes allowed, expiration and any other app-specific metadata. You might want to set a short time for the client lifetime so you don't have a bunch of unused client entities in your AS. For example, maybe browser-based clients should expire after one day. I know some people feel like too many client entities in the AS is somehow bad... but personally for high value transactions, I think it's a manageable expense. We can train LLMs, but we can't afford a few extra bits in the database to track the software performing sensitive transactions on our behalf? This would be a great topic for discussion on the IOH Livestream: https://gluu.co/ioh-home :-) - Mike -------------------------------------- Michael Schwartz Gluu Founder/CEO m...@gluu.org https://www.linkedin.com/in/nynymike -- *CONFIDENTIALITY NOTICE* This message may contain confidential or legally privileged information. If you are not the intended recipient, please immediately advise the sender by reply e-mail that you received this message, and delete this e-mail from your system. Thank you for your cooperation
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
