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 In that example, Zapier *is* the client that needs the information from the AS in order to proactively notify the user. 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 > 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. 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 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]
|
