Security and authentication

ArcGIS Platform supports secure access to location services and private data. It ensures that only valid, authorized users and services access protected information. To access secure resources, you need to implement an authentication method so your applications can make authenticated requests to services.

An authentication method is the process used obtain an access token. Your app must present an access token whenever it makes an authenticated request to location services. Access tokens define the scope and permissions available to your application. The authentication method you use to get an access token will vary.

There are three kinds of access tokens:

• API key: a permanent token that grants your application access to ready-to-use services and, with an ArcGIS Developer account, private content (currently in beta).
• ArcGIS identity (formerly named user): grants a short-lived token, generated via OAuth 2.0, giving your application permission to access the content and services authorized to an existing ArcGIS user's account.
• Application credentials: grant a short-lived token, generated via OAuth 2.0, authorizing your application to access ready-to-use services.

To make authenticated requests to services, you need to set the token parameter to an access token.

ArcGIS identity

An ArcGIS identity, also known as a named user login, grant a temporary access token giving your application permission to access the content and services authorized to your application user's ArcGIS Online or ArcGIS Enterprise account. This temporary token is created using OAuth 2.0 protocol and authorizes your application to act on the user's behalf without revealing their secure password to your application. Any service credits your application consumes are billed to the authenticated user's ArcGIS subscription and, during the authenticated period, your app can access your user's content on their behalf.

Use ArcGIS identity when you want to:

• Ensure users are signed in and authenticated with their own ArcGIS account.
• Use your app user's credits to pay for their private data, content, or service transactions.
• Limit the length of time users can be signed in to your app with a temporary token.
• Distribute your app through ArcGIS Marketplace.

API keys

An API key is a permanent access token that grants your public-facing application access to specific, ready-to-use services, and, with an ArcGIS Developer account, private content, items, and limited client referrers (currently in beta).

Use API keys when you want to:

• Quickly write applications that consume ready-to-use services.
• Provide access to services without requiring users to sign in with an ArcGIS account.
• Use an access token that doesn't expire.

Use API keys in your ArcGIS Runtime app

An API key can be used to authorize access to specific ArcGIS Online services and resources from your app, as well as to monitor access to those services. An API key is created and managed in the ArcGIS developer dashboard and is tied to your ArcGIS account.

You can set an API key on the ArcGISRuntimeEnvironment, which will apply the key to all requests your app makes for ArcGIS Online services and resources. You can also set an API key on any ArcGIS Runtime class that implements ApiKeyResource. When you set an API key for a specific class, it will override any key you may have set on ArcGISRuntimeEnvironment, enabling more granular usage telemetry and management for ArcGIS Online resources used by your app.

Classes that implement ApiKeyResource include:

• Basemap
• ArcGISSceneLayer
• ArcGISTiledLayer
• ArcGISVectorTiledLayer
• ServiceFeatureTable
• ExportVectorTilesTask
• LocatorTask
• GeodatabaseSyncTask
• ClosestFacilityTask
• RouteTask
• ServiceAreaTask
• ExportTileCacheTask

Application credentials

Application credentials grant a short-lived access token, generated via OAuth 2.0, authorizing your application to access ready-to-use services, such as basemap layers, search, and routing.

Use application credentials when you want to:

• Access ready-to-use services with a more secure process and a short-lived token.
• Provide access to services without requiring users to have an ArcGIS account.

Choose an authentication method

The choice of which type of authentication to implement is primarily dependent upon the resources required by your application. Also consider the strengths and limitations of the API or SDK technology on which your application is built. Your choice of authentication method is also affected by the API with which you build your application. For example, ArcGIS Runtime APIs provide an AuthenticationManager, with helper methods and patterns to implement ArcGIS identity workflows.

Authentication manager

ArcGIS Runtime APIs contain an AuthenticationManager, which provides helper methods and patterns for implementing ArcGIS identity workflows.

Set a central authentication challenge handler that will allow your users to authenticate with secured services

The DefaultAuthenticationChallengeHandler class can take care of showing an authentication dialog for all types of security that ArcGIS supports (including OAuth and certificates, read more below about each of these options), allowing users to provide credentials or choose a certificate (as appropriate for the service). The easiest way to ensure your app allows users to authenticate is to set an instance of the DefaultAuthenticationChallengeHandler onto the AuthenticationManager:

1
 AuthenticationManager.setAuthenticationChallengeHandler(new DefaultAuthenticationChallengeHandler(context));

Alternatively, implement and set a custom AuthenticationChallengeHandler, to customize the logic or user interface of handling authentication challenges.

Manage an in-memory cache of credentials

When a user is challenged and enters credentials which successfully allow access to the resource, those credentials are automatically added to the AuthenticationManager.CredentialCache. When secured resources from the same server and port are accessed subsequently, credentials in this cache are reused automatically, avoiding unnecessary challenges. Certificates are also cached, see below for more details.

If your app allows a user to sign out of a portal or server, call AuthenticationManager.CredentialCache.clear() to remove all cached credentials when the user signs out, to prevent users accessing resources for which they do not have permission.

The credential cache can be serialized to json, enabling it to be stored between app sessions. However, the serialized credential cache should be secured using an appropriate mechanism for your platform to ensure that credentials are not available to other apps or processes.

Manage the certificates for accessing certificate secured resources

Authentication challenges issued for self-signed server certificates can be handled as follows. Use the setSelfSignedCertificateListener(SelfSignedCertificateListener) method to provide a listener that will handle self signed certificates as they are encountered (Other types of AuthenticationChallenge will continue to be sent to the current AuthenticationChallengeHandler). This approach is useful when you want to add specific logic for trusting self-signed certificates on a case-by-case basis, but the behavior of the DefaultAuthenticationChallengeHandler is suitable for all other authentication challenges.

For testing purposes, setTrustAllSigners(boolean) can be called with a value of true to indicate an app is willing to trust all valid, non-expired, self-signed certificates. This should never be used in production code.

Manage a set of OAuth configurations

If your app will connect to OAuth secured resources, and you have set an instance of the DefaultAuthenticationChallengeHandler onto the AuthenticationManager, then add an OAuthConfiguration for a specific client ID and portal by calling addOAuthConfiguration(OAuthConfiguration). The set of OAuthConfiguration is stored in-memory only and does not persist between sessions. When using the DefaultAuthenticationChallengeHandler for OAuth, you need to also use the DefaultOAuthIntentReceiver.

Using OAuth login manager directly

You can also use OAuthLoginManager directly for custom OAuth login flows, but this is not necessary when using the DefaultAuthenticationChallengeHandler. If you do use the OAuthLoginManager, then you need not set OAuthConfiguration on the AuthenticationManager.

What's Next?

For more information about Security and Authentication, see the Security and Authentication chapter.

Tutorials

Access services with OAuth 2.0

Samples

Authenticate with OAuth

Integrated Windows authentication

Token authentication

Portal user info