According to this SF StackExchange answer, the OAuth 2.0 JWT Bearer Token flow only need a one-time authorisation of the app certificate, and then you can forever issue a OAuth 2.0 JWT Bearer Token request to receive a bearer token for all of your API authentication needs.
However, at least this guide on force.com says:
After the request is verified, Salesforce sends a response to the client. Token responses for the OAuth 2.0 JWT bearer token flow follow the same format as authorization_code flows, although no refresh_token is ever issued. A JWT OAuth 2.0 bearer token flow request looks at all the previous approvals for the user that include a refresh_token. If matching approvals are found, the values of the approved scopes are combined and an access_token is issued. If no previous approvals included a refresh_token, no approved scopes are available, and the request fails as unauthorized.
... which I read like implying that there must have been at least one authentication session that included returning
refresh_tokens as part of that flow (like the standard web-server flow, where the user is presented with a login page). And, assuming
refresh_tokens expire after some time, it would also mean that you'd need to periodically issue a
refresh_token-returning flow just to keep a Refresh token around while you use the JWT Bearer flow server-side.
Is this correct? Seems weird to me. How is this supposed to work for "Service" accounts that are created for the sole purpose of being accessed by server applications?