> I'll also implement a simple way to refresh the token in case it gets breached

I'd advise to implemented this in a way that you can have at least 2 tokens valid at any given time. So that you give your users the chance to rotate them without downtime.

Or N tokens with a note field so that if you have multiple integrations you can assign one to each or share them - much nicer when you want to invoke access or roll tokens.

Nice idea, thanks for the feedback.

That's just the way Google chooses to use OAuth when handling user data.

OAuth works just fine for machine-to-machine too, see f.ex https://developers.google.com/identity/protocols/OAuth2Servi...

Good for developers, but no necessarily end users. Even if you intend this only for development purposes, or for technical users, without doubt, some developers will ship their integrations to non-technical end users with instructions to: log into the dev portal, generate a token, add the token here, upload certificate, etc, etc.

As simple as that is, it causes headaches non-technical users, which will end up in the support queue.

Hence OAuth.

But now you have an easy way, and a hard way, and the easy way is how every developer will begin their integration. You'll need to incentivize, or gatekeep, in order to have them complete their integration with OAuth.

Maybe consider a configurable option for the token to only work as a POST payload, versus a url parameter. When they get passed around as urls in email, etc, they tend to get exposed pretty quickly. Breaks standard REST, but...

Or maybe some shared secret challenge/response to get a time limited ticket?

I'll almost certainly have it only allowed in headers irregardless of the HTTP verb used. This does mean you won't be able to use your browser to test GET's, but this feature is squarely aimed at developers who will probably be using a Postman like tool to test with.

> I'll almost certainly have it only allowed in headers irregardless of the HTTP verb used. This does mean you won't be able to use your browser to test GET's,

There is very probably a way to (ab)use HTTP Auth for this such that it's still possible to test GETs with simple URL strings or links in a browser.

I wonder if a header would be a good place for a token.

It won't get exposed like a URL parameter and doesn't misuse the body/POST.