I still don't understand why refresh tokens expire. On Fri, Nov 14, 2025 at 6:58 PM Neil Madden <[email protected]> wrote:
> Ok, the same point still stands though. > > Also, it occurs to me that the AS could indicate “your grant is about to > expire” by simply not returning a refresh token on the last refresh flow > (after all, why issue one if you know the grant will expire before it will > be used?). > > (But then again I’m also not really clear why you’d issue a RT to a > confidential client that expires before grant does). > > But these issues can wait until after adoption. > > — Neil > > On 14 Nov 2025, at 17:28, Aaron Parecki <[email protected]> wrote: > > > In that example, Zapier *is* the client that needs the information from > the AS in order to proactively notify the user. > > On Fri, Nov 14, 2025 at 9:24 AM Neil Madden <[email protected]> > wrote: > >> Ok, that makes sense, and I’m not against adding this if it’s useful. It >> seems to me generally better if the AS (Zapier in this case) just took care >> of this rather than every client having to implement it, but it’s a fairly >> lightweight addition to the spec. >> >> — Neil >> >> On 14 Nov 2025, at 17:05, Max Gerber <[email protected]> wrote: >> >> >> > So the user uses the app often enough that this prompting can happen at >> some point near to expiry, but not often enough to notice a gap in service? >> >> The point is for the user to be prompted before expiry, so no gap in >> service occurs. There are plenty of "set-and-forget" OAuth connections - >> anything that involves syncing data from one place to another comes to >> mind. I have some Zapier integrations with various systems that I use >> daily, but I barely touch the zapier dashboard anymore now that the initial >> connection is set up. Sure, Zapier could notify me after the connection >> breaks, but that would be pretty disruptive. I'd need to figure out how to >> sync all the missed events across different systems, and my coworkers that >> depend on the integration working would be left in the dark until I come >> back to fix it. For personal usecases, a small gap in service might be >> fine. For enterprise usecases, it's a much bigger deal. >> >> On Fri, Nov 14, 2025 at 8:29 AM Neil Madden <[email protected]> >> wrote: >> >>> On 14 Nov 2025, at 16:08, Aaron Parecki <[email protected]> wrote: >>> >>> >>> >>> This has already been discussed and presented in the several past IETF >>> meetings about this draft. >>> >>> >>> It sounds like something should maybe be added to the document then if >>> it keeps coming up? >>> >>> >>> Yes, it means the client can prompt the user in the UI to tell them they >>> will need to re-authorize and re-approve access. This lets the client >>> proactively tell the user they need to re-authorize before the access is >>> lost. Without this, the client will lose access for an indeterminate amount >>> of time until the user realizes the client has stopped working and goes and >>> reconnects it. >>> >>> >>> So the user uses the app often enough that this prompting can happen at >>> some point near to expiry, but not often enough to notice a gap in service? >>> And the app has no backchannel notification mechanism (eg email) to inform >>> the user that access has expired? >>> >>> — Neil >>> >>> >>> On Fri, Nov 14, 2025 at 7:51 AM Neil Madden <[email protected]> >>> wrote: >>> >>>> >>>> >>>> > On 14 Nov 2025, at 15:14, Max Gerber <[email protected]> wrote: >>>> > >>>> > > […] The client can also schedule a notification to the user to >>>> renew the grant in 11 months. >>>> >>>> But what does this mean in practice? Asking them to re-login and >>>> re-approve the scopes? If so, why not just wait for the grant to expire and >>>> do that anyway? What is the concrete benefit to user or developer >>>> experience of this field? >>>> >>>> — Neil >>>> _______________________________________________ >>>> OAuth mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
