AccessTokenCredential CreateAsync throws exception when accessing resources in federated server

[EricLiu]

Hi, I'm running into an exception, please help me confirm if this is a bug with ArcGIS or if I used the methods incorrectly. The setup is something like this:

1. User signs into an enterprise portal (let's call Portal A) via OAuth. Our app calls 'AuthenticationManager.Current.RegisterServer' and then 'AuthenticationManager.GenerateCredentialAsync'.

2. User signs-out of the portal. We call 'AuthenticationManager.Current.RemoveAllCredentials' during the sign-out process.

3. User signs into a different ArcGIS portal. This time they go access a token-secured resource belonging to Server A. Server A is federated with Portal A.

Expected Behavior:

We get a challenge for Server A. Server A's 'ServerInfo.TokenAuthenticationType' is 'ArcGISToken', so we prompt the user for the username and password. Then we call 'AccessTokenCredential.CreateAsync(Server A's ServiceUri, username, password)' to get a token for the resource. It should return a valid token.

Actual Behavior:

When calling 'AccessTokenCredential.CreateAsync', it attempts to sign-in to Portal A by calling 'IOauthAuthorizeHandler.AuthourizeAsync'. This shouldn't happen because we've already signed out of Portal A, and it should have no record of Portal A.

If we've never signed into Portal A before accessing the token-secured resource, then everything works fine as described in the expected behavior. If we sign out of Portal A and close the app (& runtime) before calling 'AccessTokenCredential.CreateAsync', it also works fine. 

Since 'AccessTokenCredential.CreateAsync' works fine in some cases but not others, it makes me think its a bug with Esri (cached server infos not cleared ?). But maybe federated servers are unique and I'm not handling the challenge correctly. 

[EricLiu]

Also, when I'm signed into a portal, and access a token-secured resource from a server that's federated with the portal I'm signed into. It's not automatically re-using my portal credentials for the server. Instead the ChallengeHandler calls CreateCredentialAsync for me to generate a new one.

[EricLiu]

I think it some places we are still using the old OAuthTokenCredential. Could it be because I have to call AddCredential on a OAuthUserCredential in order for the credential to be reused for my federated server ?

[pnarkhede]

Hi @EricLiu ,

I’m assuming you are using the legacy authentication workflow (relying on AuthenticationManager global state), as this behavior stems from cached ServerInfo. RemoveAllCredentials() clears credentials but not the ServerInfo cache. Because this cache persists, the SDK remembers the federation with Portal A even after sign-out.

There isn’t a supported public API to remove those cached ServerInfo entries in the legacy authentication system.

​My recommendation would be to migrate to the newer authentication APIs to avoid this class of issues. ​If you must continue using the legacy workflow, restarting the application is currently the only supported way to clear that cache.