Ok that's interesting observations thank you.
This behavior makes sense to me. I'll explain the whole flow at the end of this post to hopefully make it clear. In general, we expect most people to never need to turn off the service. I'm sure you have good reasons for disabling an identity/turning off the tunneler, but that is not how we currently operate.
Oh. Interesting. So you're saying it DOES recover after what a human (me or you) would consider "far too long" -- like minutes. This is also a helpful observation, thank you!
do you know how long your refresh token is valid for? It could be that?
At this time, the tunnelers only store the refresh token in memory and that memory is erased when the user turns an identity off. This is why every time you turn off the service/the identity you are forced to reauthenticate. This behavior could change but we would need to implement it (aka -- more work) and it is a valid security concern since the refresh token could be used to obtain other tokens.
How It Works Right Now
This part of the post will describe how this all works. It's in the weeds a bit maybe so skip it if you're not interested in the "whys" and details. 
- User turns on a tunneler
- tunneler tries to authenticate to the openziti overlay
- overlay indicates the tunneler can use external authentication
- tunneler knows the external providers configured and lets the user pick one to auth with
- tunneler and user complete an Auth code with PKCE flow to the authorization server. this results in two or three tokens being retrieved from the authoriztion server: an ID token, an Access token, a refresh token. Not all authorization servers support refresh tokens or the
offline_accessscope fwiw. Keep note of this refresh token, it's important later. - tunneler uses the token specified in the external jwt signer to authenticate to openziti overlay
- user does tunneler things.... makes http requests etc. every request to dial requires a valid token from the authorization server
- at some point the tunneler realizes the access token (or id token) is going to expire.
- IF the tunneler has a refresh token from the authorization server, it's used to obtain a new access/id token from the authorization server
- IF the tunneler could not obtain a new token the UI should change over to the "authorize idp" view and the user will need to authenticate to the idp again
- the new id/access token is then used for new service dial requests (http, ssh, whatever)
- rinse repeat this cycle until the refresh token expires
Ok, hope this helps and thanks so much for your insights and observations so far. I have not had a moment to be able to test/replicate this issue but I am trying to get to the point where i can. Cheers!