What is Client Authentication?
Client Authentication uses OAuth 2.0 to delegate third-party client applications access to your instance's RESTful Application Program Interface (API), thereby allowing only authorized applications to call your API. OAuth 2.0 is an open standard for authorization authentication to authorize devices with access tokens rather than credentials.
As an Administrator, manage how client applications get their access tokens to authenticate to your instance, thereby providing better security for which applications can access your instance.
When creating or editing a client application authentication, configure how your ProcessMaker Platform instance obtains the token that grants access to your API. Use one or more of the following grant types:
Redirect URL when granting the client authorization: Use Authorization Code Flow, used by web and mobile applications, to specify the URI or URL where to send the authorized application after it is granted an access token to your API.
Enable password grant: Optionally, use Resource Owner Password Flow to authenticate legacy desktop applications which directly send a username and password to receive an access token to your API. If ProcessMaker Platform as the authorization server recognizes these credentials, the authorization server returns an access token to the client application. Resource Owner Password Flow is not as secure because it does not require a callback, so it is not best practice to use this authorization method unless granting the access token to a legacy desktop application. Furthermore, this authentication method typically does not support refresh tokens and assumes that the Resource Owner and Public Client are on the same device. Use Resource Owner Password Flow for when you have a client application that only authenticates with OAuth 1.0.
Enable personal access tokens: Optionally, use a personal access token (PAT) as an alternate password to authenticate the client application into your environment if that application supports its use. The third-party application developer is responsible for creating the PAT.
If necessary, delete an authenticated client to remove its access token. Created access tokens are not set to expire, so they should be deleted periodically, and then recreated. As a best practice, delete and then recreate application developer access tokens for the following reasons:
By revoking an application developer's access token, you require that developer to manage the application token.
Requiring application developers to manage their access tokens increases security to your environment's API.
Revoking access tokens ensures that application developers do not share them with others for whom they are not intended.
View All Authenticated Clients
The Auth Clients page displays all authenticated clients in one table that Administrators throughout your organization have created. This makes it easy to manage authenticated clients to allow these users to access your RESTful API. The most recently created authenticated clients display at the top of the table.
Permission
Your user account or group membership must have the "Auth Clients: View Auth Clients" permission to view the list of authenticated clients unless your user account has the Make this user a Super Admin setting selected.
See the Auth Clients permissions or ask your Administrator for assistance.
Follow these steps to view all authenticated clients:
Log on to ProcessMaker Platform.
Click the Admin option from the top menu. The Users page displays.
Click the Auth Clients icon
from the left sidebar. The Auth Clients page displays Client Secrets for all authenticated client applications.
"Auth Clients" page displays all authenticated clients that can access your RESTful API
The Auth Clients page displays the following information in tabular format about authenticated clients that can access your RESTful API:
Client ID: The Client ID column displays the Client ID for the authenticated client. The Auth Clients automatically generates the Client ID value when the client authentication is created and represents a sequential number of how many total authenticated clients have been created to that time.
Name: The Name column displays to whom the client authentication applies. See Create a New Client Authentication Key or Edit an Authentication Client.
Redirect: The Redirect column displays the URI or URL where to send the authorized application after it is granted an access token to your API if the the Enable Authorization Code Grant option is used to grant an access token for that client application. See Create a New Client Authentication Key or Edit an Authentication Client.
Client Secret: The Client Secret column displays the Client Secret for the authenticated client. The Auth Clients automatically generates the Client Secret when the key is created. Click the Copy Client Secret to Clipboard icon
to copy the Client Secret. Paste the Client Secret into your authorization server.
No Client Authentication Keys?
If no authenticated clients have been created, the following message displays: No Data Available.