I am thinking to implement a REST service that needs to call another REST service that is protected by OAuth2.
My service is "always" called server to server by web applications.
The user interacts with the web applications using their authentication.
The server-to-server call is executed on behalf of the authenticated user.
The third party service uses the standard OAuth authentication that expects the browser to call a specific url passing a return url and the level of authorization required. The return url (that in my case must point to my service) must contain also a "state" that the service will use to validate the call and to know which user initiated the authorization (the service stores somewhere an association between the "state" and the authenticated user).
The problem is that the browser needs to call this return url directly and so without authentication.
It is my service that generates the URL to initiate the authentication. The "state" specified in the return url is stored in a database and associated with the authenticated user.
My question is: is it safe enough to use the "state" (see https://auth0.com/docs/protocols/oauth2/oauth-state) to protect this URL?
Can this URL be open and just check that the passed state is valid?
If it isn't enough, what can be done to secure this call without implementing a full authentication between the browser and the service?
When the service is called with the return URL it executes the following steps:
- It uses the authorisation code received to get the access-token and the refresh-token.
- It stores them in a record associated to the user (the service knows which user started the login process thanks to the association mentioned before).
- It redirects the browser back to the web application to a url that the web application passed when the request to login was initiated. This url must be "safe" (meaning that the state of the application does not change in any relevant ways as a consequence of opening that url).