To summarize my findings above
There are two methods to authenticate a user whether that is via the Web Console or API.
- Local User (User is created locally in Orchestrator)
- Domain User (User record is created locally in Orchestrator with a reference to the domain)
When using a local user credential, the user can log in using the Orchestrator web console login form.
These same credentials can be used to access the API assuming the user has the right roles and permissions to request the specific endpoints. In order to do so, you must first authenticate your user and receive a Bearer Token in return which will be used on your subsequent API requests
Authenticate against by POST to
Content-Type application/json, Accept: application/json
The body at a minimum should have the following JSON payload
The response will include a Bearer Token noted in the
result key. It will be much longer
Make another API request such as for the list of Machines
Content-Type: application/json, Accept: application/json, Authorization: Bearer 0c_L7-baK_afadsfasdfasdfadfuzjIWsTT1L1PoIkH..........PcNWqITasdfasdfadfasdfCg
Note that the Authorization header’s value is prefixed with
Bearer followed by the token provided in the authorization result
When authenticating as a domain user on the web console (If auto-login is not enabled) the user would click the Windows icon below the login form.
When authenticating with NTLM this is configured by default in IIS as one of the Authentication Providers for the UiPath Orchestrator site.
For authenticating with the API, you do not need to do Step 1 as indicated with the Local user. Instead, when querying an endpoint instead of providing a Bearer Token in your Authentication header you provide an NTLM token.
Authorization: NTLM wfiyauerfpoauyif;asdyfapw8yefpawf
This is why when accessing/testing the API through the Swagger UI, you do not need to authenticate yourself.
In addition, as I noted in one of my earlier posts, you can set a local password on a domain user, but keep in mind that these are two separate passwords (One local to Orchestrator and one for the Domain user) for the same user record in Orchestrator.
In summary, I do find it a bit misleading and the documentation could be clearer as well as it could be simplified by allowing domain users to enter their domain credential into the login form/authorization endpoint, as I would expect with many other services out there.