How does ArcGIS Server token authentication work?

Answer

Note:
This article pertains to ArcGIS versions 9.x through 10.2. Newer, supported versions of ArcGIS Enterprise enable HTTPS by default.

ArcGIS Server supports two methods of authentication - web-tier (including Integrated Windows authentication, PKI, and HTTP Basic/Digest) and GIS-tier authentication (also known as token authentication). One method must be chosen, the methods cannot be combined.
For highest security, web-tier authentication is recommended. GIS-tier may be used in less secure environments if the architecture dictates a load balancer instead of a web adaptor or in situations where the web server has no means to integrate into the user store that ArcGIS Server is using (such as ArcGIS Server built-in accounts).

This article explains how token authentication works and how it should be configured.

When ArcGIS Server is configured to use GIS-tier authentication, client applications ask the user for their username and passwords. Those client applications then send the username/password to ArcGIS Server and receive a token in exchange. That token can then be used on subsequent requests so that the username/password do not need to be sent.

If ArcGIS Server is not configured properly there are security risks to using tokens. The following is a discussion of those risks and what should done about them.

Risk 1. Leaking username/passwords

All Esri clients and APIs send usernames and passwords over https (encrypted) if it is enabled. If it's not enabled, then usernames/passwords may be sent as clear text over the network. To prevent this, it is strongly recommended that https be enabled in ArcGIS Server when using GIS-tier authentication. It is not enabled by default.

Risk 2: Replay attacks

A common attack is to sniff network traffic and acquire information like tokens for re-use in a malicious attack. An attacker who acquired an ArcGIS Server token from a user would be able to pretend to be that user for a period of time.

There are ways to mitigate this kind of attack. The strongest is to require https for all communications, which encrypts everything sent to and from ArcGIS Server.

There are also ways to mitigate this through the token settings for ArcGIS Server. ArcGIS Server issues both short- and long-term tokens. Long-term tokens must be bound to an IP address or an referrer. When a token is bound to an IP, only tokens coming from that IP address are accepted. This means that a replayed token from another machine is rejected. When a token is bound to a referrer, it means that unless a specific http header called a referrer is set, the token is rejected. Client applications decide whether to use referrers or IP addresses. Utilizing the referrer may decrease the security of the implementation, therefore it is not recommended.

Short-term tokens don't need to be bound to an IP address or a referrer because the period in which the token is valid is often very short which makes it harder to replay. The maximum time period for short-term tokens can be configured so that it can be shortened down to as little as a single minute.

Risk 3: Development Practices

Tokens can be acquired through either an HTTP GET or an HTTP POST. Using a POST is always more secure. GET requests may leave usernames/passwords in network equipment history and in the browser history. Esri APIs and products use POST when acquiring tokens. However for the convenience of people writing scripts, tokens can be acquired via GET requests. Esri recommends against obtaining tokens via GET requests in secure environments.