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 types of authentication that can be used to obtain an access token:
- API key authentication: This creates a permanent token that grants your application access to location services and, with an ArcGIS developer account, private content.
- User authentication (formerly ArcGIS identity): This generates a short-lived token via OAuth 2.0, authorizing your application to access location services, content, and resources on behalf of a logged in ArcGIS user.
- App credential authentication: This generates a short-lived token via OAuth 2.0, authorizing your application to access ready-to-use services on your behalf.
To make authenticated requests to services, you need to set the
token parameter to an access token.
User authentication is a set of authentication workflows that allow users with an ArcGIS account to sign into an application and access ArcGIS content, services, and resources. The typical authentication protocol used is OAuth2.0. When a user signs into an application with their ArcGIS account, an access token is generated that authorizes the application to access services and content on their behalf. The resources and functionality available depend on the user type, roles, and privileges of the user's ArcGIS account. This authentication type was previously known as Named user login and ArcGIS identity.
Service your app accesses through user authentication will be billed to the authenticated user's ArcGIS account and its associated ArcGIS subscription. If your application will access your users' secure content in ArcGIS or if you plan to distribute your application through ArcGIS Marketplace, you must use user authentication.
Implement user authentication 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.
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.
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
AGSArcGISRuntimeEnvironment, 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
<AGSAPIKeyResource>. When you set an API key for a specific class, it will override any key you may have set on
AGSArcGISRuntimeEnvironment, enabling more granular usage telemetry and management for ArcGIS Online resources used by your app.
Classes that implement
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
Authentication, with helper methods and patterns to implement user authentication workflows.
|Your app requires access only to ready-to-use services, such as the basemap layer, geocoding, or routing services.||API key|
|Your app allows users to view and edit private data in ArcGIS.||user authentication|
|Your app is on a web server or API backend and requires access only to basemaps and geocoding.||Application credentials|
|Your app uses Esri Leaflet, Mapbox GL JS, or OpenLayers.||API key|
|Your app uses an ArcGIS API.||API key or user authentication|
ArcGIS Runtime APIs contain an
Authentication, which provides helper methods and patterns for implementing user authentication workflows.
AGSAuthenticationManager class allows you to manage authentication/security related events.
It raises an
AGSAuthenticationChallenge whenever an authentication or security issue is encountered anywhere in the API. It also provides a default challenge handler which displays UI containing information about the challenge and presents appropriate options to the user, for instance, requesting a username and password. If you want to handle authentication challenges yourself, for example to display your own custom UI, you can provide your own delegate
It also maintains a cache (in memory) of credentials that have been previously used to satisfy authentication challenges. This allows credentials to be reused, where appropriate, and prevent unnecessary or duplicate challenges from being issued while accessing secure resources from the same security realm. Additionally, the cache can easily be persisted in the keychain (See
AGSCredentialCache ) so that if the app is restarted, the cache is automatically pre-populated with saved credentials and the user does not have to sign in again.
For more information about Security and Authentication, see the Security and Authentication chapter.