Kaizen #116 - Client Types in Zoho API Console

Kaizen #116 - Client Types in Zoho API Console

Hello everyone!
Welcome back to another post in the Kaizen series!

This week, we will discuss different client types available in Zoho API Console, and when to use each.

When you register an app in Zoho API Console, you typically choose a client type based on how your application interacts with Zoho services.
Let us discuss the available client types and how authorization is handled for each.

Available client types

  1. Server-based
  2. Client-based
  3. Self client
  4. Non-browser-based
  5. Mobile-based

1. Server-based

If you have a web-based application that runs on a dedicated HTTP server and interacts with Zoho services by calling Zoho APIs via that server, you must register your app with this client type.
This client type is for applications that redirect the users to another URL on a web browser to authorize themselves, where they give consent to your application to use their data.
In other words, you must use this client type when you have a front-end web UI and require user intervention before your app can access user data via the dedicated server.

Consider that you are developing a web-based custom application. Users authorize that app via browser to allow their Zoho CRM data to be accessed and used by that application.
During the registration process in Zoho API Console, you would choose the "Web-based" client type.
OAuth 2.0 would be used for user authentication, allowing your app to securely access and interact with Zoho CRM data on behalf of the users.

Here is a gist of what happens:
  1. Users visit your website where you have the Login with Zoho button.
  2. When a user clicks it, that user will be redirected to accounts.zoho.com with the details of your app such as client ID, scope, redirect uri, access type as the URL parameters.
  3. Your app must make an API call to Zoho Accounts with the client ID, scope, redirect uri, and access type. Users are shown the data that your application wants to use.
  4. When users give their consent, Zoho redirects them back to your app.This will be the "Redirect URL" you give while registering your app.
  5. The redirect URL will have the authorization code(grant token) as one of the parameters, along with the location(user's domain).
  6. Your app must then make API calls from your web server to Zoho Accounts to generate access and refresh tokens with the generated grant token.
  7. You must store these tokens in your DB to access that user's data in Zoho CRM. While making API calls, you must send this access token in the header.
  8. Your app must also have the logic to regenerate access tokens from refresh tokens when the access token expires.
Note that your app must take care of storing user's details like email, organization ID, and tokens.

The following image shows the protocol flow.


You can use any of our server-side SDKs to simplify this process.
When you use our SDK, all you have to do is, generate the grant token and initialize the SDK with the client details and this token. The SDK takes care of access token generation, refreshing it, and token storage.


For more details, you can refer to the Accounts guide and CRM help doc.

2. Client-based applications

This client type is for applications that do not have a server and run exclusively on a web browser.
This is also called the Implicit flow as your app makes API calls to Zoho only when users are using your app.
This type of application loads data dynamically on the webpage, and accesses Zoho CRM data by making API calls via Javascript.

Consider the same example where there is a Login with Zoho button on your webpage.
Here is a gist of what happens when a user clicks it.
  1. Your app redirects the user to Zoho Accounts.
  2. Your app makes the authorization request with the client ID, redirect uri, scope, and response type as token.
  3. The user is shown the data that your webpage would use.
  4. When the user gives consent, Zoho Accounts sends the access token to the redirect uri as a parameter, along with the expiry time and the location of user's data in Zoho's accounts server.
  5. You can include the "email" in your scope parameter in the access token request to get user's information. The response will have a parameter called id_token that will be in the header.payload.signature format. You need to decrypt the payload section of the parameter using the base-64 decryption algorithm to get user information.
  6. Your app must then make API calls to Zoho with this access token to fetch data.
  7. When the access token expires, your app must take care of regeneration and storage.


As the API calls are made from your domain to a different domain(zohoapis.com), for security reasons, the browser will throw the CORS error. So, your domain will be registered while registering your app, and Zoho will know to allow the API calls made from that domain.

As the tokens are available on the browser itself, we recommend handling them with care.
When you use our client-side JS SDK, it automatically generates a new access token upon expiry.

3. Self Client Applications

When your application does not have a redirect URL or a UI, but performs only a backend job, and does not need user intervention, then you must choose this client type.

A self client is often used when the application and Zoho services are operated by the same entity, and you want to enable secure communication between them. For example, you have an internal reporting tool and integrate it with Zoho Analytics. In this case, both the tool and Zoho Analytics are operated by the same entity.
Similarly, consider that you have a legacy product management system and want to perform data sync between Zoho CRM and the system, then you must use the self client.

Here is a gist of what happens.
  1. You register your app as self client in Zoho API Console.
  2. You will get the client details such as ID and secret.
  3. You provide the scopes required for your app to access CRM data.
  4. You will receive the grant token.
  5. Your app must then make API calls to Zoho Accounts to generate access and refresh tokens.
  6. Your app can then use this access token to make API calls to Zoho CRM and use data.
You can refer to our older Kaizen post on this topic for more details.
Note that self client apps can also use any of our server-side SDKs. As already said, the SDK takes care of access and refresh token generation, refreshing the access token, and token storage.

4. Non-browser applications

This client type is for devices that do not have a user agent such a web browser. A TV, for instance.
Let us consider an example involving a smart TV application that integrates with Zoho ShowTime. In this scenario, the smart TV application acts as a non-browser client.
Here is how authentication is handled:
  1. You must register your smart TV app in Zoho API Console with the type "Non-browser application".
  2. Users install a dedicated Zoho ShowTime application on their smart TVs.
  3. When users launch the Zoho ShowTime application on their smart TV, they are prompted to authenticate with their Zoho ShowTime account.
  4. When they successfully authenticate, Zoho Accounts sends the grant token to your app, along with the user-code, device-code and verification URL,The user must go to this verification URL on a browser and enter the user-code to grant permission to the app.
  5. Meanwhile, your app must poll the accounts server using the grant token to check if the token has been received.
  6. When the user enters the user code, Zoho Accounts sends the access token to your app.
  7. Your app can then use the access token to make API calls to Zoho. Your app must take care of token storage and renewals.

Here is the protocol flow. For more details, refer to this doc.


5. Mobile-based applications

You must use this client type when you have developed an app exclusively for mobile devices. The protocol flow is similar to server-based application where a browser session is required for the users to authenticate.



Similar to server-side apps, mobile apps also need to handle redirection, token generation and storage.
If you use any of our Mobile SDKs, the SDK itself handles token generation and storage.

We hope you found this post useful. Let us know your thoughts in the Comment section or write to us at support@zohocrm.com.


Cheers!

    • Sticky Posts

    • Kaizen #217 - Actions APIs : Tasks

      Welcome to another week of Kaizen! In last week's post we discussed Email Notifications APIs which act as the link between your Workflow automations and you. We have discussed how Zylker Cloud Services uses Email Notifications API in their custom dashboard.

    • Kaizen #216 - Actions APIs : Email Notifications

      Welcome to another week of Kaizen! For the last three weeks, we have been discussing Zylker's workflows. We successfully updated a dormant workflow, built a new one from the ground up and more. But our work is not finished—these automated processes are

    • Kaizen #152 - Client Script Support for the new Canvas Record Forms

      Hello everyone! Have you ever wanted to trigger actions on click of a canvas button, icon, or text mandatory forms in Create/Edit and Clone Pages? Have you ever wanted to control how elements behave on the new Canvas Record Forms? This can be achieved

    • Kaizen #142: How to Navigate to Another Page in Zoho CRM using Client Script

      Hello everyone! Welcome back to another exciting Kaizen post. In this post, let us see how you can you navigate to different Pages using Client Script. In this Kaizen post, Need to Navigate to different Pages Client Script ZDKs related to navigation A.

    • Kaizen #210 - Answering your Questions | Event Management System using ZDK CLI

      Hello Everyone, Welcome back to yet another post in the Kaizen Series! As you already may know, for the Kaizen #200 milestone, we asked for your feedback and many of you suggested topics for us to discuss. We have been writing on these topics over the