ArcGIS Server uses a token-based access control system. Once users have authenticated themselves, an access token is issued to the client application. When a user needs to access secured services or perform administrative tasks, the client application sends the access token and ArcGIS Server determines whether to grant access to that service or administrative task based on the permissions of that service or the privileges of that user.
Token properties
The following sections discuss important properties of ArcGIS tokens.
Life span of a token
To maintain the security of the token, each token is associated with an expiration time. The end user may see a time-out or other error message if an expired token is used.
Tokens with shorter expiration times are more secure, as a token intercepted by a malicious user can only be used within a smaller time window. However, a short expiration time means that applications need to request new tokens more frequently.
Two parameters define the life span of issued tokens:
- Lifespan of Short-lived Tokens—When a client requests a token but does not specify a time-out value, a short-lived token is issued. The issued token is only valid for the duration defined by this property. When a client requests a token with a time-out value less than the short-lived token life span setting, a token with the requested expiration value is issued.
- Lifespan of Long-lived Tokens—When a client requests a token with a time-out value, the requested time-out value is compared with the duration defined by this property. If the requested time-out value is less than the long-lived token life span, a token with the requested expiration value is issued. If the requested time-out value exceeds the long-lived token life span setting, a token is still issued but with an expiration that matches this property.
Shared key definition
An ArcGIS token is a string of encrypted information. The shared key is the cryptographic key used to generate this encrypted string. The more complex the shared key, the harder it is for a malicious user to break the encryption and decipher the shared key. If a user is able to decipher the shared key, replicate the ArcGIS Server encryption algorithm, and obtain the list of authorized users, the user will be able to generate tokens and consume any secured resource on that specific ArcGIS Server.
Before defining a shared key, consider the following:
- The shared key should be set to 16 characters (any characters beyond 16 are not used). It is recommended that you use a sequence of random characters for the key. Any characters may be used, including nonalphanumeric characters.
- The key should not be set to a dictionary word or a common value that is easily guessed. Since there is no need to remember the key or use it elsewhere, key complexity does not pose the same issues as it does with passwords.
- The token is encrypted with the shared key using the Advanced Encryption Standard (AES), also known as Rijndael. The 16 characters in the key represent the 128 bits used for encryption. For more information about encryption and AES, consult security references or someone in your organization with expertise in security and cryptography.
- In highly secure environments, it is recommended that you change the shared key periodically. Keep in mind that if you change the shared key, you may need to update your applications to use the new shared key. All existing embedded tokens will become invalid once you change the shared key.
Secure transmission of tokens
To prevent the interception and misuse of tokens, the use of a secure connection using HTTPS is recommended. The use of HTTPS ensures that the username and password sent from the client and the token returned from ArcGIS Server cannot be intercepted.
When building custom ArcGIS client applications that use GET requests to access web services secured using ArcGIS token-based authentication, it is recommended that the token be sent in the X-Esri-Authorization header instead of a query parameter. This prevents intermediaries on the network, such as proxies, gateways, or load-balancers, from being able to obtain the token. The example HTTP GET request below sends the token in the X-Esri-Authorization header: GET https://arcgis.mydomain.com/arcgis/rest/services/SampleWorldCities/MapServer?f=pjson HTTP/1.1
Host: arcgis.mydomain.com
X-Esri-Authorization: Bearer xMTuPSYpAbj85TVfbZcVU7td8bMBlDKuSVkM3FAx7zO1MYD0zDam1VR3Cm-ZbFo-
If ArcGIS Server uses ArcGIS Server authentication and not web-tier authentication (IWA, HTTP BASIC, PKI, and so on), the standard HTTP Authorization header may be used instead of the X-Esri-Authorization header: GET https://arcgis.mydomain.com/arcgis/rest/services/SampleWorldCities/MapServer?f=pjson HTTP/1.1
Host: arcgis.mydomain.com
Authorization: Bearer xMTuPSYpAbj85TVfbZcVU7td8bMBlDKuSVkM3FAx7zO1MYD0zDam1VR3Cm-ZbFo-