Would be nice if there would be a possibility to replace the Authenticator after creating the Client

[fseidl-bauradar]

As already requested by

#1015

it would be a nice Feature if RestSharp Handles the JWT Access- and RefreshToken.
In the current Implementation, a Authenticator Implementation is not able to Refresh the JWTTokenPair,
if the AccessToken is going to exceed runtime.
Because to Refresh The Token Pair, the Authenticator would need a to perform a RestRequest to the Server and therefor a RestClient.
But neither the DI neither a user can provide the RestClient, because to Construct a RestClient, we need to set the Authenticator.
This leads to a Circular Dependency, which is not solveable.

A possibility would be to Create another RestClient, for the Authenticator, but I don't think this would be a clean solution to the problem.
Another solution is to use the Interceptor Pattern Implementation, as provided in the PullRequest, bellow, because the Interceptors are provided inside a List, they can be changed even after the RestClient have been created.
As I think the Authenticator is a special form of the Interceptor Pattern, therefor this solution fits in mine optionion.
Additionally, I would say it's not unusual to allow adding Interceptors at any time.

#2076

[LukeFranky]

100% agree. This used to be possible, but was deprecated for some reason and now I have bunch of refactoring to do. Frustrating!

[bbuehrer]

Is there anything new on the subject?
I also need to be able to change the authenticator after creating the RestClient.

[fseidl-bauradar]

Sorry, currently I am waiting, seems like the maintainer is little bit busy

[abc123xxx]

Is there anything new on the subject?
I also need to be able to change the authenticator after creating the RestClient.

[rassilon]

@LukeFranky , @bbuehrer , @fseidl-bauradar, I mentioned in another issue recently that RestRequest has an Authenticator property that you can use on requests that require a different authentication mechanism than the default.

The reason that the property is now read-only is for thread safety reasons.

[abc123xxx]

Yes, that is the solution

[fseidl-bauradar]

@LukeFranky , @bbuehrer , @fseidl-bauradar, I mentioned in another issue recently that RestRequest has an Authenticator property that you can use on requests that require a different authentication mechanism than the default.

The reason that the property is now read-only is for thread safety reasons.

@rassilon Could you add the issue where you mentioned that the RestRequest has an Authenticator property?

[alexeyzimarev]

Closing this in favor of #2361, which reframes the problem and provides a proper solution.

The root cause here wasn't really about replacing the authenticator after client creation — it was that the existing OAuth2 authenticators don't manage the token lifecycle (acquisition, caching, expiry, refresh). Users needed to do that externally, which led to the circular dependency problem described in this issue.

The fix in #2361 adds three new self-contained authenticators that handle the full token lifecycle internally using their own HttpClient for token endpoint calls. This eliminates the circular dependency entirely — no need to replace the authenticator or make options mutable.