What is Client Authentication?
Learn more about OAuth 2.0 to delegate user accounts access to your environment's RESTful API.
Overview
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.
Related Topics
pageView Authenticated ClientspageEdit an Authenticated ClientpageDelete an Authenticated ClientpageCreate a New Authenticated ClientLast updated