I'm working on an API that I'd like to be accessible internally by other servers as well as devices that I consider both as confidential private clients. Devices are considered private clients because the client_secret is stored in an encrypted area that prevents from unauthorised readout and modification (even though nothing is never bullet proof)
For auth, I'd like to use OAuth2 with the
client_credentials grant that seems to be a very good fit for these use cases. However I'm wondering how flexible is the standard regarding sharing the client_secret.
Basically the RFC doesn't say much about sending your client id / client secret, it just offers an example here: https://www.rfc-editor.org/rfc/rfc6749#section-4.4.2 which is very simple by using the following header Authorization Basic: base64(client_id:client_secret)
In my opinion, it could be slightly more secure by computing a hash:
- the client requests a random to the server by sending their client_id
- the server replies with a random code (valid for like 10 mins, just like an authorization code)
- the client computes a hash = sha256(client_id, client_secret, code) and asks for a token
- the server computes the same hash, compares the client hash with the computed hash and sends an access token if they match
It would add an extra layer of security in case https is somehow broken or if anyone is able to read the header somehow.
However it doesn't seem very OAuth2 compliant and I don't really like re-inventing a standard. Another option would be to create my own extention grant, I'm just wondering if it's really worth it, like no one seems to have done this.
Also, if I want to share my API with a 3rd party app, not sure it's a good thing to force them into using something non really standard.