Getting Started
Drupal module
Connect Drupal to DocID®, provision native users, map verified attributes to roles, and protect content.
The official DocID® module connects Drupal to one of the largest online networks of healthcare professionals. It uses Drupal-native users, roles, permissions, sessions, nodes, media, and blocks so professional content can be made available to a broad audience through familiar Drupal workflows.
Open the DocID® module on Drupal.org
Prerequisites
- A Drupal website using HTTPS and permission to install and configure modules
- A DocID® account with a configured website asset and OAuth credentials
- Drupal core File, Filter, Node, Options, and User modules; Media is optional for protected media
Install the module
Using the administration interface
Download the current package from the DocID® project on Drupal.org. In Drupal administration, open Extend → Add new module, upload the archive, and complete the installation.
Using Composer
Run the following command from the Drupal project root:
composer require drupal/docidActivate the module
Enable DocID® under Extend in Drupal administration. Alternatively, enable it with Drush and rebuild caches:
drush en docid -ydrush crConfigure OAuth and requested customer data
- Open Configuration → People → DocID® → OAuth credentials.
- Copy the displayed callback URL into the allowed redirect URIs of the corresponding website asset in the DocID® business dashboard.
- Enter the asset Client ID and Client Secret.
- Under Requested customer data, keep openid and professional enabled and activate only the optional profile, email, or phone data the website needs.
Available scopes
| Scope | Status | Claims |
|---|---|---|
| openid | Required | sub |
| professional | Required | profession_id, discipline_id, profession_verified |
| profile | Optional | name, title, given_name, family_name, gender |
| Optional | ||
| phone | Optional | phone_number |
Native users and role mapping
A successful DocID® login provisions or updates a linked native Drupal user using the stable sub claim. Accounts are not linked by email. Role mappings can target all DocID® users or exact profession, discipline, institution, or subject identifiers. All matching non-administrative roles are combined, while roles assigned independently by Drupal remain unchanged.
Protect content and media
Editors can choose Public, Only DocID® users, or Only selected roles in the DocID® access settings of supported content. Role-specific rules use Drupal node access. Protected local media must use Drupal’s private file scheme so delivery continues through Drupal authorization.
Login destinations
Configure profession- or discipline-based Drupal-internal destinations under Login destinations. Lower priority numbers win when several mappings match. A protected page requested before authentication takes precedence over a profile-based destination.
Available smart tags
The module provides DocID® Account Navigation, DocID® sign-in, and DocID® account blocks. To use smart tags in editorial content, enable the DocID® smart tags filter for the relevant trusted text format.
Authentication and navigation
The login link is state-aware: it shows sign in to visitors and logout to authenticated DocID® users. Its login_text and logout_text attributes customize both labels. The username tag uses the best available value in this order: title, first name and last name; title and last name; authorized email address; stable DocID® user ID.
| Shortcode | Description |
|---|---|
| [docid-loggedin-content]Content[/docid-loggedin-content] | Shows the enclosed content only to authenticated DocID® users. |
| [docid-loggedout-content]Content[/docid-loggedout-content] | Shows the enclosed content only to visitors without an authenticated DocID® session. |
| [docid-login-link] | Shows Sign in to visitors and Log out to authenticated DocID® users. |
| [docid-login-link login_text="Access" logout_text="Leave"] | Uses custom plain-text labels for both authentication states. |
| [docid-username] | Shows the best available username: title, first name, and last name; then title and last name; then the authorized email address; and finally the stable DocID® user ID. |
Profile data
| Smart tag | Scope | Description |
|---|---|---|
| [docid-profile-id] | openid (required) | The stable, unique DocID® account identifier. |
| [docid-profile-name] | profile (optional; authorization required) | The combined title, given name, and family name. |
| [docid-profile-title] | profile (optional; authorization required) | The title or form of address. |
| [docid-profile-given-name] | profile (optional; authorization required) | The given name. |
| [docid-profile-family-name] | profile (optional; authorization required) | The family name. |
| [docid-profile-gender] | profile (optional; authorization required) | The gender value. |
| [docid-profile-email] | email (optional; authorization required) | The transferred email address when available. |
| [docid-profile-phone-number] | phone (optional; authorization required) | The transferred phone number when available. |
Access authentication status and claims in PHP
For application code, load the identity linked to the current Drupal user through the IdentityRepository service. In production code, inject the current_user and repository services into your class instead of using the static service container.
use Drupal\docid\Identity\IdentityRepository; $current_user = \Drupal::currentUser();$identity = $current_user->isAuthenticated() ? \Drupal::service(IdentityRepository::class) ->findByUserId((int) $current_user->id()) : NULL; $is_docid_authenticated = $identity !== NULL;$docid_subject = $identity?->subject;$claims = $identity?->claims ?? []; $profession_id = is_string($claims['profession_id'] ?? NULL) ? $claims['profession_id'] : NULL;$discipline_id = is_string($claims['discipline_id'] ?? NULL) ? $claims['discipline_id'] : NULL;$institution_id = is_string($claims['institution_id'] ?? NULL) ? $claims['institution_id'] : NULL;$subject_id = is_string($claims['subject_id'] ?? NULL) ? $claims['subject_id'] : NULL;$profession_verified = ($claims['profession_verified'] ?? FALSE) === TRUE; // Optional claims exist only when their scope was authorized.$name = is_string($claims['name'] ?? NULL) ? $claims['name'] : NULL;$email = is_string($claims['email'] ?? NULL) ? $claims['email'] : NULL;$phone = is_string($claims['phone_number'] ?? NULL) ? $claims['phone_number'] : NULL;Test before launch
- Open public and protected content while signed out.
- Complete sign-in with an eligible test account and verify the return to the originally requested content.
- Continue without optional profile data and confirm that authentication still works with the required scopes.
- Test every configured role mapping and login destination, including a non-matching account.
- Sign out and confirm that protected content is no longer accessible.
The integration supplies technical authentication and access-control features. Website operators remain responsible for choosing appropriate scopes, permissions, notices, and legal bases for their implementation.