Incorrect token used with hosted feature service?

[timmorey]

When using OAuth to authenticate as a named user in the browser, I'm seeing the oauth token being used on requests sent to federated services. My understanding is that the oauth token should be exchanged for a token on the particular service.

For example, I created a hosted feature service in www.arcgis.com, which is only accessible by my named user.

In a browser, I authenticate as that named user using the IdentityManager in the ArcGIS API for Javascript v4.11, which provides me with a credential.

When I access the layer in arcgis-rest-js

getLayer({ 
  url: layerUrl, 
  authentication: UserSession.fromCredential(credential) 
})

I see that it uses the token stored in credential.

In contrast, when I access the layer in the ArcGIS API for Javascript

const layer = new FeatureLayer({ url: layerUrl })
layer.load()

I see that the token stored in credential is exchanged for a service token using the generateToken endpoint on the service, and that token is used to fetch the layer info.

While both approaches succeed in fetching the layer info, I'm wondering if arcgis-rest-js should use generateToken to get a service-specific token.

I see that there is code in place to support the generateToken workflow, but in my tests its not being used. The code in

arcgis-rest-js/packages/arcgis-rest-auth/src/UserSession.ts

Lines 724 to 730 in b956d91

	public getToken(url: string, requestOptions?: ITokenRequestOptions) {
	if (
	(arcgisOnlinePortalRegex.test(this.portal) ||
	arcgisOnlineOrgPortalRegex.test(this.portal)) &&
	arcgisOnlineUrlRegex.test(url)
	) {
	return this.getFreshToken(requestOptions);

is deciding that we don't need to generate a token for the service. The regular expressions are basically determining that we're authenticated with www.arcgis.com, and the requested resource url contains .arcgis.com. I think this test may be too loose.

[patrickarlt]

@timmorey you are exactly right but this behavior is 100% intentional and one of the differences between ArcGIS REST JS UserSessions and the JS API IdentityManager.

ArcGIS REST JS takes a shortcut In order to avoid the additional requests required for the full token exchange (failed request, get server info, get new token, retry request with token) if we can detect if the service is hosted on .arcgis.com and the user is authenticated with arcgis.com. The reason this test might seem a little loose is there is a pretty large spread of URL patterns we need to accommodate here.

The main reason for the full token exchange is like you said to prevent the users "portal token" from being sent to an unknown server or service. This shortcut operates on the assumption that everything under arcgis.com domain is trusted and known which since all of it is managed by Esri.

[timmorey]

@patrickarlt thanks for the response. I'll close this one, since it appears to be working as designed, and I don't have a concrete case where it is causing problems.

As a little context, we have an app in production that has been directly communicating with the rest api using ajax, and we were passing the portal token on requests to hosted feature services. Some users had been experiencing sporadic 503 errors, and one hypothesis was that this was caused by the use of the incorrect token. We had been given the recommendation to always exchange the portal token for a service token whenever it is used outside of the sharing api. We were evaluating if we might be able to pull in this library to get that behavior (as well as a lot of other nice stuff you guys have built).

[tomwayson]

Thanks for the context @timmorey.

We have been using this library in production for about a year, and v2 (w/ the updated token flow) since we released it a couple months ago. We have not noticed any sporadic 503 errors.