Skip to main content
The Research Desk Demand API leverages email-password combinations to authenticate API access, and utilizes JSON Web Tokens (JWT) to authorize each API call. This authorization standard enables developers to build fully secure applications, easily manage access, and provide better experiences for end users. Prior to implementing authentication and authorization, please read the following sections to determine the workflow which best fits your needs. Hybrid workflows are common, such as a user-facing application passing authentication credentials from a browser while storing a set of credentials server-side to authenticate API calls powering a recurring job.

​
External End-User Authentication

Although rare, there are cases in which integrations directly leverage the Research Desk Demand API authentication and authorization system to manage external end users. In this case, the external user’s email address and password should be passed directly from the browser to the Research Desk Demand API. Once authenticated, the returned token should be stored in a browser cookie, along with the given expiration. When a user action warrants an API call, the expiration stored in the cookie should be validated and the token is directly passed into the authorization header of the API call. If the expiration has passed, the user should be prompted to re-enter their email address and password, creating a new token which can then overwrite the previously stored token. When an end user wishes to terminate their session, the token value and timestamp stored in the browser cookie should be destroyed; there is no API action necessary.

​
Internal User Authentication

For applications which are exposed to users within your company, single sign-on (SSO) integrations are highly recommended. The Research Desk Demand API supports Security Assertion Markup Language (SAML) based single sign-on authentication and authorization. This method of authentication enables companies to manage user access to the API using their consolidated system of choice, and prevents credential exposure. To obtain certificates and additional information, please contact your Rep Data account manager. If your company does not leverage SSO, internal users’ browser sessions can be authenticated and authorized in the same method as the recommended external end-user workflow detailed above. Internal users may also leverage their email address and password combinations to authenticate via non-custom applications such as Postman.

​
Server-to-Server Authentication

Credentials can be created, stored, and leveraged on the back-end of any application. It is highly recommended to create separate credentials for disparate categories of functionality, such as one set of credentials used as a proxy for end-user activity and a separate set used to authorize API calls necessary for a recurring job or alerting system. Once a token is generated using a set of credentials, the expiration should be stored and validated prior to executing any API calls.
⌘I