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.
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
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.
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.
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.