Hello Tushar; I also have a use case for which access to the ArcGIS Online (AGOL) token is required. Our team is prototyping a solution that we intend to deliver after ArcGIS Pro 1.3 is released. We are eagerly awaiting this release for the "solution Based Configuration" presented at Dev summit earlier this year (by Charlie Macleod and Steve van Esch) in order to migrate a .NET runtime application into an ArcGIS Pro solution. We currently have a security model that leverages AGOL authentication to additionally secure our ASP.NET standalone services which in turn access token-secured services from an on premises ArcGIS Server. It is somewhat complex, but necessarily-so for a variety of business reasons. The model works well, and requires only a single sign-on to AGOL in order to provide security to the entire spectrum of services accessed by the client application. When we migrate to ArcGIS Pro we will require access to the AGOL token via the Pro API in order to pass it to our proprietary services to work with the existing security model. As you mentioned, the EsriHttpClient class internally appends tokens to requests when needed, but I am concerned about two things in that regard: That the system does not recognize the need to append the token when calling our internal (non-portal) service. That all HTTP requests in our solution will have to be modified to use the EsriHttpClient class exclusively for this purpose. This is a significant change across our solution, and it will impact our decision to proceed in this direction. Given that it is technically possible to examine the HTTP requests post-modification we can envision a hack solution that will allow us to obtain the Token, but we would much prefer to access the token via a sanctioned API method. Please consider augmenting the API with support for this capability. Regards, Dave
... View more