OAuth 2.0 Applications options

<< Click to Display Table of Contents >>

Navigation:  Environments identity and access management >

OAuth 2.0 Applications options

Overview

Whenever you need a external application to invoke Bizagi using the features of different services (OData, Azure Active Directory, System for Cross-domain Identity Management, etc.), you must first register the OAuth keys (clientSecret and clientID) used for its authentication in the OAuth 2 Applications option of the Work Portal's Admin menu. As these services in Bizagi are protected and rely on this standard authentication mechanism (OAuth version 2.0), requests made to these services need to be granted with rights to resources, using the previously generated OAuth keys.

 

With the OAuth version 2.0 specification, Bizagi supports the three OAuth flows, which are the most commonly used ones:

 

Authorization code:

This lets client application authenticate users with inputted credentials at runtime (throughout a login page).

This flow is designed for human interaction, where requests use impersonation of end users.

For more information about this specification, refer to https://tools.ietf.org/html/rfc6749#section-1.3.1.

 

Client credentials:

This allows server to server integration without further use of specific end user credentials.

For more information about this specification, refer to https://tools.ietf.org/html/rfc6749#section-1.3.4.

 

Bearer Token:

This lets client application authenticate using a token.

For more information about this specification, refer to https://tools.ietf.org/html/rfc6750.

 

This article explains the different options you have when registering an application in OAuth 2 Applications.

 

Register Application options

To register an external application, you must first go to the Work Portal and, under the Security section of the Admin menu, select the OAuth2 Applications option.

 

OAuth2Apps_options_01

 

This option lists the services being accessed by Bizagi devices, and allows you to include additional applications that represent granted access to the services by providing the appropriate access keys.

 

Click the option to add a new record to this table:

 

OAuth2Apps_options_02

 

This opens the Register Application window, where you have the following options:

 

OAuth2Apps_options_03

 

 

Option

Description

Name

Unique and representative name that allows to identify the application being registered.

Grant type

Authorization Code

Grant type used to integrate web or mobile applications, in which the application receives an authorization code via the redirect URL. Before obtaining the token, the authorization code is sent to the authorization server to reduce the possibility for attackers to get the token directly.

Client credentials

Grant type used to obtain an access token in the context of a user (e.g. obtain an access token as an administrator). Is commonly used when you need to use a Bizagi feature without considering all the application's users (e.g., when you want to use the OData layer, as the admon user). With this grant type, there is no need to send an authorization code, and the OAuth keys are validated directly to get the access token.

All

Grant type used to obtain the token via an authorization code, client credentials or a bearer token. In other words, the way in which the external application requests the token can be any of the other grant types described.

Bearer token

Grant type used as an HTTP authentication scheme, so an external application using the OAuth keys pair can obtain an access token directly, sending these keys in the authorization header of the HTTP request (e.g., when synchronizing users using SCIM). This grant type is recommended under an HTTPS secure connection.

Web site

Associated web site URL.

Allowed Scope

API

When checked, the token allows to make full use of the OData services.

LOGIN

When checked, the token allows the Bizagi project to become an IdP (authenticator) to access other Bizagi projects. This scope is recommended especially when using Authorization Code as the Grant type.

USER SYNC

When checked, Bizagi uses the SCIM standard to retrieve user information from an external system. Hence, you must check the scope when synchronizing users using SCIM.

ODATA QUERY

When checked, the token gives a specific permission to execute the Work Portal queries using the Query endpoint of the OData services.

RPA

When checked, the token gives a permission to answer Automation Anywhere Callbacks.

User Name

Applies when using Client credentials or All as grant type.

 

Name of an existing Bizagi user (make sure you select it from the suggested list of matching users).

User Domain

Domain to which the previously selected user belongs.

Redirect Strategy

Web Application

Redirects the user to a web URI using the code obtained from the authorization server.

Mobile Title Bar Browser

Value used when the application redirects the user to a mobile device app. As mobile devices don't have an endpoint, the request is redirected sending the authorization code in the title HTML tag, so the mobile device can get it from there.

Mobile Localhost Port

Bizagi sends a code to https://localhost:port/, where a mobile device can get the one sent by the authorization server.

Redirect URI

Applies when using Authorization Code or All as grant type.

 

URL to which the user is directed in the callback after providing their credentials. The URL should always be defined using HTTPS.

Token lifetime (mins)

Number of minutes for which a same token is valid and can be reused for another invocation (this limit enhances security while avoiding replay attacks). If no value is specified, Bizagi considers that the token never expires (infinite lifetime).

Life cycle type

Absolute

Token life cycle type in which the authentication session expires once the token lifetime times out, regardless of whether the external system was used or not. When a time out occurs, a new token must be negotiated.

Sliding

Token life cycle type in which the authentication session expires once the token lifetime times out but, unlike the absolute token life cycle type, the session time resets each time the external system is used.

Description

Brief description of the registration.

 

Once you have finished selecting and filling in the options you require, click the Save button. The OAuth keys (clientSecret and clientID) are generated for authentication of the external system you just registered. Save these keys in a secure place and use them to grant access to the external application.