DocID®DocID® Documentation
Back to DocID®
  • Overview

    • DocID® Documentation
  • Introduction

    • Introduction
    • How DocID® works
    • Core concepts
  • Getting Started

    • Getting Started
    • Drupal module
    • WordPress plugin
    • Custom website
    • Go-live checklist
  • Features

    • Features
    • Standard Login
    • Access and personalization
    • Analytics
    • Campaigns
  • Licenses

    • Licenses
  • OAuth 2.0

    • OAuth 2.0
    • Configure a client
    • Authorization code flow
    • Scopes and UserInfo
    • Security and environments
  • API

    • API
  • Help

    • Troubleshooting

Getting Started

Custom website

Prepare a server-rendered website or web application for DocID® OAuth.

Use a custom integration when your platform is neither Drupal nor WordPress, or when you need direct control over sessions, routing, and profile-based behavior.

Prerequisites

  • A backend capable of keeping credentials and tokens secret
  • HTTPS callback routes
  • A server-side session mechanism
  • A DocID® client for each environment

Create two application routes

Your application normally needs:

  1. A login route that generates state, nonce, and the PKCE values before redirecting to DocID®
  2. A callback route that validates the response, exchanges the code, reads the approved claims, and creates a local session

Store temporary authorization data in a signed, HTTP-only, secure, same-site cookie or in a server-side transaction store.

Request authorization

Redirect the browser to /oauth2/authorize with:

1response_type=code2client_id=YOUR_CLIENT_ID3redirect_uri=https://your-domain.example/auth/docid/callback4scope=openid professional5state=RANDOM_UNGUESSABLE_VALUE6nonce=RANDOM_UNGUESSABLE_VALUE7code_challenge=BASE64URL_SHA256_CODE_VERIFIER8code_challenge_method=S256

Handle the callback

On the server:

  1. Reject callbacks with a missing or mismatched state.
  2. Handle an OAuth error response without exposing technical details to the user.
  3. Exchange the authorization code at /oauth2/token.
  4. Send the original code_verifier.
  5. Request /oauth2/userinfo with the access token.
  6. Map sub to your local account or session.
  7. Remove the temporary OAuth transaction data.

See the complete OAuth 2.0 flow

PreviousWordPress pluginNextGo-live checklist

On this page

  1. Prerequisites
  2. Create two application routes
  3. Request authorization
  4. Handle the callback