JWT "no-brainer" choice is for any UI app which will need to
authenticate user as well any API calls which require authorization on
the API not just authentication.
Both API key and JWT can provide authentication and authorization. API key is on project scope and JWT is on user scope.
API keys are considered to be vulnerable to man-in-the-middle attacks, so not as secure as authentication tokens (refer to Google Cloud API key doc).
Example use case for API keys is using Endpoints features such as quotas. Each request must pass in an API key so that Endpoints can identify the project that the client application is associated with.
Example use case for JWT is authentication between Microservices. Refer to this doc for details on use case with more than this two authentication method.
how does it look when JWT is used by API (direct call, no UI) and is
not "static" and that will require to generate refresh token for it.
How in a general way API should to handle it? Should be that done per
When the client logs in, the authorization server API issues access token and refresh token, and sends them back to client in response. They are both JWT but refresh token is much long-lived compared with access token. The client stores the access token in the
HttpOnly cookies. Refresh tokens are usually subject to strict storage requirements to ensure they are not leaked. Until the access token expires, the client uses it to call the API endpoint. When it expires, the client sends the refresh token to the auth-server, and the server issues new access token.
Please refer to this article for more details on refresh tokens.
Note you may not have to store and use refresh token at all.