Third-Party Application Registration API Using OAUTH 2:Overview

[Sandeep_raj]

Third-Party Application Registration API Using OAUTH 2:Overview
Third-party applications can be accessing the products of UiPath through API authentication (OAuth2). These can be achieved using the External App registration in the orchestrator. The UiPath Resources which can be accessed are as follows:

There are two types of Application registration as follows:
a) Confidential Application
b) Non-Confidential Application

• Confidential Application:
• Confidential applications can hold credentials in a secure way without exposing them to unauthorized parties. They require a trusted backend server to store the secret.
• Grant Type: Since they use a trusted backend server, confidential applications can use grant types that require them to authenticate by specifying their client ID and client secret when calling the Token endpoint. They can use either the Post or the Basic Token endpoint authentication method.
• The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner’s user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.

     Fig: Authorization Code Flow (Confidential)

• Non-Confidential Application

• UiPath uses PKCE (Proof Key for Code Exchange) protocol for registering non-confidential applications.
• Non-confidential applications are those applications that will not store the client’s secret key.
• PKCE (RFC 7636) is an extension to the Authorization Code flow to prevent CSRF and authorization code injection attacks.
• PKCE is not a replacement for a client secret, and PKCE is recommended even if a client is using a client secret.
• PKCE is not a replacement for client authentication, it does not allow treating a public client as a confidential client.
• PKCE was originally designed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, even web apps that use a client secret.

                         Fig: PKCE Protocol

Access Token and Refresh Tokens
• Access Token: Access tokens are fetched from the authorization endpoint and these access tokens are only valid for 60 minutes.
• Refresh Token: Refresh token can be called with the access token where we receive both refresh token and access token. The refresh token is single-use and valid for 60 days.

SCOPES
• There are two types of scopes: Application based and User-Based Scopes.
• User-Based Scopes: Granting permissions under user scope means that the external application can access those resources within a user context and a user with the appropriate permissions must be logged in.
• Application Based Scopes: With permissions under application scope, the external application has access to application-wide data for the selected scopes without the need for user interaction. Non-confidential applications cannot access the application scope.
• If the external application has been registered with user scopes, we must add a Redirect URL where the external application should receive the authorization response.
• If only application scopes are selected, providing a Redirect URL is optional.
• Application-based scope will grant permissions based on the application level.

WORKAROUND WITH UiPath

• REGISTRATION OF THIRD-PARTY APPS

a) Navigate towards the Orchestrator Admin External application in the orchestrator.

b) Click on Add Applications

c) After clicking we will be getting an App registration page and application names need to be provided and application types needed to be given based on the requirements.

d) Scope needed to be added based on the application type and permission required by clicking on the Add Scopes Selecting the resource and giving the appropriate scopes needed.

Please note that for non-Confidential applications we have only User-based Scope.

e) Redirect URL needs to be added for the non-Confidential application where the external application will receive the authorization request. For connection with non-confidential applications redirect URL should be provided, in this case, we are using Postman redirect URL

f) After adding the application, we will get the Client id and client secret (The client secret is based on the Application registration type) which can be used for the authorization.

ENDPOINTS FOR AUTHORIZATION

Please Note that the identity_ is for Automation cloud and identity is for on premise.