Skip To Content ArcGIS for Developers Sign In Dashboard

When you implement authentication in your application there are certain best practices you should employ in your code and development process. Anything available on the client-side is subject to compromise. A security breach in your application could lead to a hacker getting access to your credits, accessing resources they are not permitted to see, or possibly data loss. There are things you can do to reduce your exposure. It is beyond the scope of this article to present comprehensive security advice. Therefore we offer the following practical advice to help you think about building a secure application.

Usage concerns for app login

The tokens you receive from performing app login can be used for any ArcGIS Online premium content or service. This means that if you put a token in the open, such as in a browser or client app, another developer or attacker could look at your token in the console and use the token to make requests. This usage will be billed to your account. Because of this we advise that you take at least some precautions before putting a token in the clear.

Request the shortest token expiration possible

You can use the expiration parameter when requesting a token to set the amount of time a token is valid for. By requesting shorter tokens you limit the time-frame an attacker can use a compromised token.


Use HTTPS/TLS to communicate with the service. This will help prevent man-in-the-middle and packet sniff attacks. You should fully validate the certificate with a trusted CA.

Never expose sensitive information

You should never expose your client_secret under any circumstances. You should always treat your client_secret like a password and never reveal it to anyone. Do not include sensitive tokens, passwords, or client secret information as literal strings in your code. This also means you should never check your client_secret into a source control system such as Git or SVN. If someone has your client_secret they can use it to create tokens and then use those tokens to access premium content and service which will be billed to your account. To mitigate this risk we suggest using a proxy service when you require a client_secret in your app.

Proxy service

A proxy is a service that functions as an intermediary between a client (such as your app) and a target service. Your client-side app sends security sensitive requests to a proxy, the proxy adds the necessary secrets, and then forwards the request to the intended service. The service sends the reply back to your proxy and your proxy forwards the reply back to your app. This technique protects your tokens from exposure to client side applications. You can control usage by configuring which services can be proxied, which referrers are allowed to proxy requests via the HTTP Referrer header, and you can set rate limits on services.

Esri provides two methods you can choose from to deploy a proxy service for your app:

  1. ArcGIS Online hosted proxies configured on the ArcGIS for Developers website providing publically accessible endpoints for many premium services.
  2. A self-hosted resource proxy built in PHP, .NET, or Java that can proxy any ArcGIS service. Esri provides the source code on GitHub.

These proxies can be configured with your Client ID and Client Secret and used in conjunction with either the ArcGIS Runtime SDK, ArcGIS API for JavaScript, Esri Leaflet, or REST.

See our guide to working with proxies for a more detailed description of using a proxy service with your application.

The ArcGIS Resource Proxy source code is available on GitHub.

Require login

Require named user login over app login. By requiring users to sign into your app, only authenticated users would be able to access private content and/or premium content and services and consume credits.

Use an ArcGIS SDK

The best practice and recommended flow for applications requiring security is to use the appropriate client SDK object model to connect to and authenticate with ArcGIS Online rather than doing it directly via the REST API. Performing connection and authentication via the client SDKs frees you from authentication details as well as the responsibility of safely handling user credentials during the authentication process.


If you are worried about bots and automation driving up your usage you can also implement a CAPTCHA to differentiate humans from bots. Google's reCAPTCHA is a great way to implement a CAPTCHA without a significant impact on your user experience.

Adhere to security policy

Perform code reviews and validate adherence to your organization's security policy. Use a third-party testing service to verify your secure implementation.