OAuth 2.0 for Zoho Recruit APIs - An Overview
The Zoho Recruit API uses the OAuth2.0 protocol for authentication. It is an industry-standard protocol specification that enables third-party applications (clients) to gain delegated access to protected resources in Zoho via an API.
Why should we use OAuth2.0?
Clients are not required to support password authentication or store user credentials.
Clients gain delegated access, i.e., access only to resources authenticated by the user.
Users can revoke the client's delegated access anytime.
OAuth2.0 access tokens expire after a set time. If the client faces a security breach, user data will be compromised only until the access token is valid.
How OAuth2.0 works?
The following are some terms you need to know before you start using the Zoho Recruit APIs.
The Zoho Recruit resources, such as Candidates, Contacts, Job Openings, etc.
The Zoho Recruit server that hosts protected resources.
Any end-user of your account, who can grant access to the protected resources.
An application that sends requests to the resource server to access the protected resources on behalf of the end-user.
The consumer key generated from the connected application.
The consumer secret generated from the connected application.
Authorization server provides the necessary credentials (such as Access and Refresh tokens) to the client. In this case, it will be the Zoho Recruit authorization server.
The authorization server creates a temporary token and sends it to the client via the browser. The client will send this code to the authorization server to obtain access and refresh tokens.
A token that is sent to the resource server to access the protected resources of the user. The Access token provides secure and temporary access to Zoho Recruit APIs and is used by the applications to make requests to the connected app. Each access token will be valid only for an hour and can be used only for the set of operations that are described in the scope.
A token that can be used to obtain new access tokens. This token has an unlimited lifetime until it is revoked by the end-user.
Zoho Recruit APIs use selected scopes, which control the type of resource that the client application can access. Tokens are usually created with various scopes to ensure improved security. For example, you can generate a scope to create or view a lead, or to view metadata and so on.
Scopes contain three parameters — service name, scope name, and operation type. The format to define a scope is scope=service_name.scope_name.operation_type
Here, ZohoRecruit is the service API name, modules is the scope name, and ALL is the operation type.
|Scope Name||Associated Methods|
|settings||settings.all, settings.custom_views, settings.related_lists, settings.modules, settings.fields, settings.layouts|
|modules||modules.all, modules.candidate, modules.client, modules.contact, modules.jobopening, modules.campaign, modules.task, modules.event, modules.call, modules.interview, modules, modules.custom,modules.notes,modules.assessment,modules.candidatestatus,modules.jobopeningstatus, modules.todo,modules.custommodule,modules.vendors,modules.application,modules.referral,modules.department,modules.assessment_submission,modules.forecast|
|bulk||bulk.all, bulk.read, bulk.create|
|notifications||notifications.read, notifications.create, notifications.update, notifications.delete|
Group scopes provide complete access to all functions the user can perform on the record. For instance, a group scope can allow a user to read, create, update, and delete records in all modules.
In the above example, the user has access to all modules in the client ZohoRecruit account.
Other examples are
Separate scopes are used to provide access to data in a particular module without access to other modules.
The above scope gives the user access to only the candidates and Job Openings modules from the client ZohoRecruit account.
Additionally, you can set specific permissions, like read, create, update or delete, for each module. For examples: