I’ve read through your documents for client_credentials as this is the flow we need to implement. I’m trying to develop a proof of concept through Auth0 for our company with for one of our Resources.
If we trust the client app to keep their credentials secret and only communicate over SSL are there any vulnerabilities that we need to be concerned with?
For example, is there a chance our token could be obtained (and if so, how) and then used by a malicious client to gain access to our Resource?
So far the information I’ve read through indicates that the reasons why tokens expire is to reduce the possibility that they can be used by a different client.
Apologies if this information is already listed in a document and I’ve missed it, as there is a lot of information.
I imagine that these vulnerabilities are already handled by Auth0 - sort of it’s purpose, I just want to be able to explain how protected we are to others in the company.
Thanks.
As you mentioned, most of the OAuth2 security characteristics assume the use of TLS/SSL as the primary means to avoid disclosure of sensitive information. For example, if the client application is correctly configured to validate the TLS certificate available at the token endpoint then this dramatically reduces the risk of the client credentials being leaked duting communication and the same could be said of the access tokens that are transmitted to the resource server as those endpoints should also be making use of TLS.
Of course there are other countermeasures that need to be considered and some are within the sole scope of the authorization server and that’s one of the main reasons why delegating those aspects to a service that focus on authentication and authorization is so important. Since software security is a moving target, having someone that focus on it and continuously evolves it will provide much better characteristics then trying to roll your own at the same time you need to implement your business requirements. For example, the client secrets being used by Auth0 have high entropy and we also have rate limiting in place in order to provide a countermeasure to brute-force attacks that could be used to guess secrets.
In conclusion, the exchange of client credentials for an access token does not happen very frequently and if you guarantee the proper storage of those credentials in the client application and then correctly configure it in terms of TLS then you’re already pretty safe.
For the access tokens, both the client application and resource server will need to take care in order to not leak them when not in transit, for example, proper storage in the client application and ensuring they are not logged on the resource server side; the in transit security aspect is again ensured by proper use of TLS.