Is it necessary to protect the Oauth2 return URL

Question

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:

1. It uses the authorisation code received to get the access-token and the refresh-token.
2. 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).
3. 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).

Answer 1

By not protecting the return url you open yourself to the flowing scenario

1. Malicious user A registers with web application
2. Malicious user A obtains initial OAuth redirect to the third party service. He can do it easily by using user agent that does not follow the redirect automatically
3. Malicious user A tricks naive user B into opening the redirect url and authenticating with the third party.
4. Naive user B completes the process - your service gets the callback and assumes it is valid. It obtains access token and associates it with user A (the one that initiated the flow)
5. User A logs in into the web applications and asks for his data - web application calls service which calls third party and now user A sees the user B data

The third step is the hardest to pull but consider thew fact that third party will tell the user B that it is Your application that is asking for permission so more trustworthy it is the easier the exploit is.

The simplest way around it would be to have the callback url on the web application, authenticate the user and simply forward the call to the service.