We have an "RESTful" endpoint that returns a newly created storage token. All the information required to generate the token is contained in the bearer token so no body is required for the request. The request causes no database change because the token is not stored. A subsequent request, without any intervening database change, provides a different token in the response. What's the right method, POST or GET?
One proposal is a GET and a GET/id where the id is the identifier for a resource used in the token creation process, not for the token itself. Alternative is a POST.
Since there's a beer riding on the result I will try not to take sides too obviously. Resources like the rules on GET and POST from IETF and the discussion of the two methods at https://restfulapi.net/http-methods/#get was not sufficient to persuade either side, in part due to differences about whether it is appropriate for a GET to return something different if the underlying resource has not changed between the requests and whether "a random token that we generate" is a new "resource" when not stored in the database.
You should absolutely use POST to generate a token.
GET is used for retrieval of a collection of existing resources or a specific resource identified by a supplied path parameter.
In this case you are not really generating a resource on the server at all. You don't store any data and there's nothing to retrieve later. So there's no REpresentational State Transfer.
However, as the token you are creating is going to be different on each call (iat and exp claims, assuming you're using JWT) and should not be cached by any intermediary. HTTP agents will treat POST requests as non-idempotent, making it the best choice for a token issuing endpoint.
See also for example the OAuth2 token endpoint mandating POST.