Rate this page

Preparing to write an application

To write a client for the Ping Identity Data Governance Broker, you will need certain details about the Data Governance Broker’s configuration. To configure the Data Governance Broker to work with your application, the Data Governance Broker administrator will need certain details about the application.

This article lists the key pieces of specific information that Data Governance Broker client developers and Data Governance Broker administrator will need to share with each other when preparing to write and roll out an application.

The following tables lists information from the Data Governance Broker configuration needed by the client developer:

Information Notes
SCIM resource types If more than one resource type is defined, then it will be helpful to know the name of the identity resource type.
SCIM schemas and attributes For each resource type, it will be helpful to know the core schemas and extension schemas. This information will also be available through the SCIM schemas endpoint.
UserInfo or ID token claims These are only needed if using the UserInfo endpoint or when requesting ID tokens without access tokens.
Scopes The configured scopes, and the attributes and operation types represented by those scopes
ACRs Applications performing OpenID Connect requests may need to know the names of the configured ACRs, as well as their intended meanings.
Public access token signing certificate This information will also be available through the JWKS endpoint.
Client credentials The client ID and client secret.
ID token signing algorithm A JSON Web Algorithm (JWA) such as HS256 or RS256. For client-side applications, an RSA-based JWA, such as RS256, is recommended.

The following tables lists information about an application needed by the Data Governance Broker administrator:

Information Notes
Client grant type The grant type, or flow, that the client will use to request access tokens and ID tokens. See choosing an OAuth 2 grant type, below.
Client redirect URLs The callback URLs that the client will use to receive OAuth 2/OpenID Connect responses.
Client web site URL This will be displayed when a user is prompted to authorize a request.
Client icon This will be displayed when a user is prompted to authorize a request.
Client contact address This will be displayed when a user is prompted to authorize a request.
Client ID token encryption public key certificate If the client requires that ID tokens be encrypted, then it must provide an RSA public key in PEM-encoded certificate form.
Origin If the client is a client-side application, then the administrator will need to know the client’s origin to configure CORS.
Required services If the client is a client-side application, then the administrator will need to know which services (e.g., SCIM, UserInfo, JWKS) are used by the client to configure CORS.

Choosing an OAuth 2 grant type

An application using OAuth 2 or OpenID Connect interacts with the authentication server using one of several possible request flows, called grant types. Assuming that your application interacts with end users using a web UI, then your choice of grant type should be determined by your application’s execution environment.

Grant type Use if
Authorization code An application with a server-side component that can communicate securely with the Data Governance Broker.
Implicit A client-side application that executes within an insecure environment, such as a web browser.