Reputation: 7812
We want to make simple authorization for server-server HTTPS communication (we control both servers) like classic API_KEY: client has hardcoded (in a config) a key which use in every request. Server check if the key is valid.
Our colleague has implemented it like OAuth2 Bearer token (RFC6750)
Authorization: Bearer client_key
So the client has the client_key
in the config, it's never refreshed. It works well, we have just a philosophical dispute in the company, if such "hardcoded" Bearer token is along with OAuth2 or not. (Disclaimer: I am not with any side of the dispute.)
Upvotes: 0
Views: 440
Reputation: 53958
The OAuth 2.0 protocol basically defines an access_token
- which is a token that is bound in time and permissions - and two protocol "legs":
You do not use access tokens (since your tokens are not bound in any way) and you've only "syntactically" implemented part 2. In fact you don't actually implement OAuth 2.0 in that case. You may present the client_key
just as well in an HTTP Basic header or in a query parameter, it has nothing to do with OAuth 2.0 except that you're borrowing (arguably: abusing...) its header name and format.
Upvotes: 1