I do think it's a practical control if you are responsible for both the server AND all the client(s) code, i.e, it's feasible for you to micro-manage the fine detail of the auth dance.
However if you are providing an oauth / oidc API endpoint to be consumed by arbitrary developers I wouldn't advise this.
The way many clients work is that refresh token stuff happens in the background as needed, "piggybacking" off the thread using the access token. Depending on how everything is set up, parallel requests can be generated.
Providing support for oidc / oauth token flows is already extremely difficult because customers will usually be using an ecosystem-specific library and usually don't understand the spec, let alone whatever stricter "best practices" you might be enforcing.
Comments
I do think it's a practical control if you are responsible for both the server AND all the client(s) code, i.e, it's feasible for you to micro-manage the fine detail of the auth dance.
However if you are providing an oauth / oidc API endpoint to be consumed by arbitrary developers I wouldn't advise this.
The way many clients work is that refresh token stuff happens in the background as needed, "piggybacking" off the thread using the access token. Depending on how everything is set up, parallel requests can be generated.
Providing support for oidc / oauth token flows is already extremely difficult because customers will usually be using an ecosystem-specific library and usually don't understand the spec, let alone whatever stricter "best practices" you might be enforcing.