Authentication overview

Disqus provides mechanisms for applications to securely interact with its API, enabling developers to integrate comment functionalities, manage user data, and access moderation tools. The choice of authentication method depends on the scope of interaction required by the integrating application. For purely public, read-only data access, a simple API Key is sufficient. However, for actions involving user-specific data, private operations, or modifications, Disqus mandates the use of OAuth 2.0, an industry-standard protocol for delegated authorization.

The Disqus API is designed to allow developers to build custom experiences, retrieve analytics, and perform bulk operations that are not available through the standard client-side JavaScript widget. Understanding the appropriate authentication flow is crucial for maintaining security and adhering to Disqus's API usage policies. It ensures that applications only have the necessary permissions and that user data remains protected.

Supported authentication methods

Disqus supports two primary authentication methods:

  • API Key (Public Key): This method is used for accessing public, read-only data from the Disqus API. It's suitable for applications that need to display public comment threads or retrieve general forum information without requiring user-specific actions or elevated permissions. The API Key identifies your application to Disqus.
  • OAuth 2.0: This protocol is essential for applications that need to perform actions on behalf of a Disqus user or access private data. OAuth 2.0 facilitates secure delegated access, ensuring that the user grants explicit permission for an application to access their data or perform actions without sharing their actual credentials with the application. Disqus supports two main OAuth 2.0 flows: the Authorization Code Grant flow, primarily for web server applications, and the Implicit Grant flow, suitable for client-side applications (like single-page applications) where a backend server is not involved in token exchange. RFC 6749 details the OAuth 2.0 Authorization Framework.

Authentication methods comparison

Method When to Use Security Level Typical Use Case
API Key (Public Key) Accessing public, read-only data. Low (identifies application, not user) Displaying public comment counts, forum details.
OAuth 2.0 (Authorization Code Grant) Server-side applications requiring user-specific permissions. High (secure token exchange, user consent) Posting comments on behalf of a user, managing user settings.
OAuth 2.0 (Implicit Grant) Client-side applications (e.g., SPAs) requiring user-specific permissions. Medium (token directly in redirect, no refresh tokens) Client-rendered dashboards displaying user's recent comments.

Getting your credentials

To integrate with the Disqus API, you must first register your application and obtain the necessary credentials from the Disqus admin panel. The process differs slightly depending on whether you need an API Key or are setting up for OAuth 2.0.

Obtaining an API Key

  1. Register your application: Navigate to the Disqus applications page. Click on 'Register new application'.
  2. Fill in application details: Provide a name, description, and website URL for your application.
  3. Retrieve Public Key: After registration, your application dashboard will display a Public Key (sometimes referred to as an API key). This key is used for read-only access to public endpoints.

Setting up OAuth 2.0 credentials

  1. Register your application: Follow steps 1-2 from 'Obtaining an API Key'.
  2. Configure OAuth settings: In your application's settings within the Disqus admin panel, locate the OAuth section.
  3. Add Redirect URLs: You must specify one or more valid Redirect URIs (or Callback URLs). These are the URLs to which Disqus will redirect the user after they authorize your application, appending the authorization code or access token. For security, these must be exact matches to what you register.
  4. Retrieve Client ID and Client Secret: Upon successful registration and configuration, your application dashboard will provide a Client ID (also known as Application ID) and a Client Secret. The Client ID identifies your application, and the Client Secret is a confidential key used to authenticate your application when exchanging an authorization code for an access token (in the Authorization Code Grant flow).

It is critical to keep your Client Secret confidential and never expose it in client-side code or public repositories. If your Client Secret is compromised, you should immediately regenerate it within the Disqus admin panel.

Authenticated request example

This section demonstrates how to make an authenticated request using both an API Key and an OAuth 2.0 Access Token with the Disqus API. These examples assume you have already obtained the respective credentials.

API Key example (Public Data)

To fetch a list of public forums, you would include your Public API Key in the request. This is typically passed as a query parameter.

GET https://disqus.com/api/3.0/forums/list.json?api_key=YOUR_PUBLIC_API_KEY
Accept: application/json
fetch('https://disqus.com/api/3.0/forums/list.json?api_key=YOUR_PUBLIC_API_KEY')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error fetching forums:', error));

OAuth 2.0 example (User-specific Data)

For operations requiring user authentication, you'll use an Access Token obtained via the OAuth 2.0 flow. The Access Token is typically sent in the Authorization header as a Bearer token.

GET https://disqus.com/api/3.0/users/details.json
Authorization: Bearer YOUR_OAUTH_ACCESS_TOKEN
Accept: application/json
fetch('https://disqus.com/api/3.0/users/details.json', {
  headers: {
    'Authorization': 'Bearer YOUR_OAUTH_ACCESS_TOKEN',
    'Accept': 'application/json'
  }
})
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error fetching user details:', error));

Security best practices

Adhering to security best practices is essential when integrating with the Disqus API to protect user data and maintain the integrity of your application.

  • Protect your Client Secret: Never expose your OAuth Client Secret in client-side code, public repositories, or unsecured environments. It should always be stored and used on a secure server-side component of your application.
  • Use HTTPS for all communications: Always ensure that all communication with the Disqus API and your application's endpoints (especially redirect URIs) occurs over HTTPS. This encrypts data in transit, preventing eavesdropping and tampering.
  • Validate Redirect URIs: Register specific and exact Redirect URIs in your Disqus application settings. This prevents malicious actors from redirecting users to compromised sites and hijacking authorization codes or access tokens.
  • Store Access Tokens securely: If your application needs to persist OAuth Access Tokens, store them encrypted in a secure, server-side database. Avoid storing them in client-side storage (like local storage or cookies) where they can be vulnerable to XSS attacks.
  • Handle refresh tokens carefully: If using the Authorization Code Grant flow, which often provides refresh tokens, store these tokens with even greater care than access tokens. Refresh tokens have a longer lifespan and can be used to obtain new access tokens. Revoke them immediately if compromise is suspected.
  • Implement State parameter for CSRF protection: When initiating the OAuth 2.0 Authorization Code or Implicit flow, include a unique, unguessable state parameter. This parameter should be generated by your application and verified upon redirection to prevent Cross-Site Request Forgery (CSRF) attacks. Google's Identity Platform documentation provides guidance on the state parameter.
  • Request minimal scopes: When initiating an OAuth 2.0 flow, request only the minimum necessary permissions (scopes) that your application needs. Over-requesting permissions can raise user concerns and increase the attack surface if your application is compromised.
  • Regularly review API access: Periodically review your application's permissions and revoke access tokens that are no longer needed. Monitor API usage for anomalies that might indicate unauthorized activity.
  • Error handling: Implement robust error handling for authentication failures. Provide clear, user-friendly messages without exposing sensitive technical details that could aid attackers.