oAuth DotNet Proxy with Portal 10.3 Error 498 Invalid Token

[PamRichmond]

Using Federated Portal 10.3 with DotNet proxy using application authentication, we are getting an error code 498 when trying to access a secure map service that was created with the same account as the registered app. I verified that the clientId and clientSecret (appId and appSecret) are valid. ArcGIS and Portal are on the same server. In case it is a factor, the web adapter was changed from "arcgis" to "portal", so logging in to Portal and the oAuth path start with https://myservername.com/portal rather than https://myservername.com/arcgis, but the map services still reference https://myservername.com/arcgis.

Error in Chrome:
dojo.io.script.jsonp_dojoIoScript1._jsonpCallback({"error":{"code":498,"message":"Invalid Token","details":[]}});

proxy.config:
<?xml version="1.0" encoding="utf-8" ?> <ProxyConfig allowedReferers="*" mustMatch="true"><serverUrls> <serverUrl url="https://myservername.com" clientId="xxx" clientSecret="xxx" oauth2Endpoint="https://myservername.com/portal/sharing/rest/oauth2/" matchAll="true"/> </serverUrls></ProxyConfig>

I get the following when doing detailed logging of the proxy (tokens modified):

2015-12-01 10:21:40 https://myservername.com/arcgis/rest/services/20151116_180423/MapServer?f=json&dpi=96&transparent=tr...

2015-12-01 10:21:40 Sending request!

2015-12-01 10:21:40 Renewing token and trying again.

2015-12-01 10:21:40 Matching credentials found in configuration file. OAuth 2.0 mode: True

2015-12-01 10:21:40 Service is secured by https://myservername.com/portal/sharing/oauth2/: getting new token...

2015-12-01 10:21:40 Sending request!

2015-12-01 10:21:40  Token obtained: to-qcTzUb_wvPLG2bxoGEadmmdpe4BTsFgHEyoqjmYi0GEJ4g1lO-ECEz28Wl8p5P5gNgc8aUA-maUxZ-beXRNlvkTRmZXxGbf-CC5oyajQ6bqX_WVTC57XDflWaza-fbw1yPF0kC7lDgB8VMHg..

2015-12-01 10:21:40  Exchanging Portal token for Server-specific token for https://myservername.com/arcgis/rest/services/...

2015-12-01 10:21:40 Sending request!

2015-12-01 10:21:41  Token obtained: bzFOQbHno6eZ2i9DUievUqHFuFctqxiIA11b3rbVGhMHtKzQ0xN29dA35QDD2U-tKJm9tfKEngF-cgoYLFiF4JqxLqSQAzavQWL3t17R6KUlx5HQAlL_mDiDP77H85N-iZDxTWDhsyUFUWgQRpw..

2015-12-01 10:21:41 Sending request!

[DerekLaw]

Hi Pam,

Can you please contact Esri Tech Support and open an incident? They would be best equipped to help investigate your issue further.

Good luck,

[SzymonPiskula1]

I have been hitting the same problem (invalid token message) when working with DotNet Proxy & OAuth. In my scenario i created an App in Portal 10.6 and I wanted to user app ID + secret to get tokens which does not work so far.  What I also observed that in my (federated) server 10.6 logs there is a message:

DEBUG

Exception caught while validating token. Invalid token.

Nothing furder, no stack trace, no details. No messages in logs around the error giving more idea about the incident.

I went further and decided to try and decode the tokens. For this i followed:

Decrypting ArcGIS Server Tokens | 

The above with some small tweaks worked really well and I could now see what is in the tokens. So my portal-exchange-to-server token (NOT access token!), after decoding, has the following content:

{"s":"aa50","t":"a","c":1528067244042,"d":"<federated-site-id>","e":true,"g":"<app-id>","h":"0123456789ABCDEF","l":0,"m":0}

So pretty much looks like a JSON. I cannot see any user login info in there though, perhaps its because this was generated from app id/secret?

BUT if i decode a token generated via:

 https://<federatedserver>/server/tokens/?request=gettoken&username=LOGIN&password=PASS

It then decodes to:

serveradmin:1528100607636:

So different syntax/shape. No more JSON, just values separated with ':'

What im wondering is if the exchange token can be used in exact same way as the old-fashion produced tokens, or if the exchange tokens need to be submitted differently/other parameter? The DotNet proxy from Esri uses the exchange-token in the same manner as the 'default' token so i would assume they are compatible? On the Server side (in backend code) do they need different handling mechanism?

Regards,

Szymon