Version 10.3 and later

Support for OAuth 2.0 was added to Portal for ArcGIS at version 10.3. Since version 10.3 you can perform named user login or app login with your on-premise Portal acting as the OAuth2.0 Server when utilizing Enterprise logins.

Create an application in your portal and register it for Oauth 2.0. Once you have a client_id and client_secret you can use any of the authentication workflows for named user login or app login.

Set the ArcGIS Online authorization endpoint with the authorization endpoint on your Portal https://<host>:<port>/<subdirectory>/sharing/rest/oauth2/authorize. You must also replace the ArcGIS Online token endpoint with the token endpoint for your portal https://<host>:<port>/<subdirectory>/sharing/rest/oauth2/token. If you are using one of the ArcGIS APIs or SDKs both of these options will often be set using a single option for the Portal URL.

OAuth 2.0 Endpoints

Authorization Endpoint: https://<host>:<port>/<subdirectory>/sharing/rest/oauth2/authorize
Token Endpoint: https://<host>:<port>/<subdirectory>/sharing/rest/oauth2/token

Version 10.2 and earlier

ArcGIS Server and Portal for ArcGIS do not support authentication via OAuth 2.0. Instead both support a generateToken REST API call that can be used with either user credentials obtained from the user who is logging in to the platform via the application or with the application's own credentials.

You can still create user experiences that mirror the OAuth 2.0 based named user login and app login with the generateToken API call.

App Login

A "user" representing the app needs to be provisioned with a username (for instance, app-username) and password (for instance, app-password). Apps targeting users unknown to the platform can login using this app-username and app-password with the generateToken API call. It's the app's responsibility to keep the app-username and app-password secure using server side code, proxy, or some other means.

The limitations of implementing app login in this manner are:

  • The identity of the app is modeled via a surrogate user.
  • There is no clear separation of users from apps in the platform.

Named User Login

Applications implementing named user login based on the generateToken call are responsible for presenting the end user with a login dialog that prompts the user for credentials. The application is responsible for keeping the user's credentials secure and transmitting them over HTTPS.

The best practice and recommended flow for such applications 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.

In the case of the JavaScript API, authentication is handled by including the IdentityManager dijit in the application. Applications can use the IdentityManager dijit to allow users to sign into their ArcGIS Online or Portal for ArcGIS accounts. Once the user has signed in, any subsequent REST requests made from within that client session using the esri.Request object will automatically be part of that authenticated session.

The following are limitations of implementing named user login in this manner:

  • The identity of the app remains unknown to the platform.
  • Users cannot sign in using federated identity providers that are accessible via the platform hosted login pages exposed via the OAuth 2.0 APIs.

Other types of authentication

If your server or portal uses HTTP, Integrated Windows (IWA), or PKI-based security instead of token-based authentication, the response to the authentication challenge from the server needs to be handled using the native communication stack of the client platform.