oAuth DotNet Proxy with Portal 10.3 Error 498 Invalid Token

4450
2
12-01-2015 08:40 AM
PamRichmond
New Contributor III

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!

0 Kudos
2 Replies
DerekLaw
Esri Community Moderator

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,

0 Kudos
SzymonPiskula1
New Contributor III

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

0 Kudos