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?
Best Answer
Nope, not quite. The need to use the refresh token flow is a one-time thing. After the user has authorized the connected app once, you can then make JWT Bearer requests for that connected app forever (or until the user explicitly revokes permission for the connected app, or until the certificate you're using for the connected app expires...though in this case I believe you'd just need to create a new certificate and upload it to your connected app).
The refresh token is never used in the JWT Bearer flow, and does not need to be stored (or updated).
Going a step further, I believe that if you set the connected app's policy to "Administrators may pre-authorize users", then you only need to go through flow that generates a refresh token once before you can specify any user assigned to one of the pre-authorized profiles.