Should Named Credentials be used to store an API Callout Bearer Token?

Question

Problem

I have a straightforward REST API callout in apex.

request.setEndpoint('https://api.websitename.com');
request.setMethod('GET');
request.setHeader('Authorization','Bearer abcdefghijklmnopqrstuvwxyz');
HttpResponse response = http.send(request);

However, I naturally do not want to hardcode the bearer token, and am looking for ways to securely store it in Salesforce. Multiple sources I've looked at (here, here, and here) suggest using Named Credentials. However, everything I've seen regarding Named Credentials seems to indicate that it is a solution for much more complex integrations than what I am trying to do. The JWT and OAuth authentication options include numerous fields I'm not familiar with at this time, and seem to be more based around creating an ongoing app than handling a simple callout.

This question/answer is very similar to mine, but the accepted (and only) answer suggests storing the bearer token in a custom object, which as mentioned in this question seems like an unideal solution. Custom Settings or Custom Metadata Types are both options as well, but don't seem to be designed with security in mind.

Question

Does securely storing just a bearer token in Salesforce merit using Named Credentials? If so, can one be configured in a way that only references the bearer token? If not, what are secure alternatives?

Edit

In case it is relevant, the API I am referencing is for the GetFeedback online survey platform, documentation here and here.

Answer 1

If possible, you should use Named Credentials with OAuth flow. There will be a one-time manual setup where you have to log in to the third-party OAuth server, but with a refresh token, it will automatically maintain an active session for you, even refreshing the access token if it expires. It's a very hands-off approach to authentication, and works well in most cases. A JWT is similar, but uses a token calculated with a different tool. It's also typically very serviceable. Finally, if the token fits in the password field, you can also cheat with my custom API key solution. Since you've already rejected most of my previous answers, perhaps that's the one that will get you across the finish line.