We’ve secured our REST server with OAuth2 and implemented the client credentials grant type for several client apps that we control. Now we’re faced with the decision to either make the tokens long lived (i.e. they expire “never”) or to have the clients reAuthenticate very often (depending on the refresh token expiration). The first means that a captured token could be used by a malicious party the second means exposing the client secret very often which then in turn can be used to obtain tokens.
Which is more secure in a resource-server to client-server authentication?
Both token and client secret can be invalidated if we suspect a theft. Obviously all communication is done via https..
Currently we’re thinking the client secret is more powerful than the token and thus a long lived token should be better for this two-legged scenario. (For any three-legged grant type which we’ll implement soon we’d prefer a short lived token acting as the user session).
Thanks for your thoughts!
According to the specification, the client credentials flow is only allowed for clients that are not running the risk of having its client secret stolen:
So, if you are using this flow in conjunction with an application on an untrusted platform, you should definitely reconsider this decision.
With the prerequisite that your platform is trusted, there is no need to worry about a stolen client secret. Your decision then comes down weighing up the time an attacker can play with a stolen access token versus the additional overhead for the reauthentication (only one call, but nonetheless a small delay). The reauthentication step itself is a non-issue concerning the exposure of your client secrect, when both participants are trusted and you’re using a good transport layer security against MITM attacks.
Also note, that it is not recommended (and also unnecessary) to use refresh tokens with the client credentials flow: