Technical requirements

Technical requirements for integrating your application with the Veracity platform and services.

If your company only needs a lead-generating site on Veracity, you can skip this section.

If you want to integrate your application with Veracity, you must meet the requirements described below.

The Veracity platform runs on Microsoft Azure and uses Azure Active Directory B2C (OpenID Connect OAuth 2.0) for authentication through the Veracity identity provider (IDP). Because of this, integration is typically easier for applications built in common programming languages and hosted on Azure, Amazon Web Services (AWS), or another major cloud platform.

Test your application

Test your application in the following environments:

  • Internal company computers (for example DNV or VERIT) and non-company computers
  • Internal company networks and external networks

Implement a sign-in button

Your application must provide a sign-in button integrated with the Veracity IDP.

The Veracity IDP manages user authentication and enables the Single Sign On (SSO) experience across Veracity services.

Implement a sign-out button

Your application must provide a sign-out button that is easy for users to locate.

The sign-out process should:

  1. Clear relevant cookies.
  2. Redirect the user to the Veracity logout endpoint:
https://www.veracity.com/auth/logout

This endpoint signs the user out of Azure AD B2C.

You can optionally add a redirectUri parameter to return users to a specific page after logout.

Example:

https://www.veracity.com/auth/logout?redirectUri=https://store.veracity.com

If the URL provided in the parameter is valid, the user will be redirected to that address.

Important considerations

  • The redirectUri parameter must match a registered service URL in a service configured in the Developer Portal.
  • The application’s logout page must instruct users to close the browser to ensure a complete logout.
  • If you use the redirect URL example above, this behaviour is handled automatically.
  • When a user signs out, the application should also delete all local session information, including cookies.

Manage subscriptions with API calls

Veracity must be able to determine:

  • which Veracity users have access to your application
  • what information about those users your application stores

This ensures that Veracity remains compliant with the General Data Protection Regulation (GDPR).

To maintain synchronisation with Veracity:

  • Create a service subscription each time you add a Veracity user to your application.
  • Call the appropriate API endpoint to revoke access when you delete or deactivate a user in your application database.

Veracity recommends implementing an admin panel in your application for managing users. This allows non-technical administrators to trigger the required API calls through standard UI actions.

Subscriptions can also be managed through the Veracity Developer Portal.

To view the available MyServices endpoints used to manage subscriptions, see Veracity MyServices subscription endpoints.

Note the following limitations:

  • The My and This viewpoints are available.
  • The Directory and Options viewpoints are not available.

Consider your authorisation model

Veracity provides user authentication and limited authorisation capabilities.

Applications with a single access level

If your application provides only one access level, you can use a service subscription as the authorisation mechanism.

Your application can call Veracity Service API endpoints to verify whether the logged-in user has an active subscription.

For details about claims returned by the Veracity identity provider, see Veracity IDP claim reference.

Applications that are open to all users

If your application is free and open to all users, an authorisation mechanism may not be required. The Veracity onboarding team will help determine the appropriate approach.

Applications with multiple access levels

If your application supports multiple access levels, you must implement access control within your application.

Example:

Your application offers Bronze, Silver, and Gold memberships.

When a user purchases a membership:

  • Veracity creates a service subscription that grants access to the application.
  • Veracity sends a service bus message indicating the purchased membership level (Bronze, Silver, or Gold).

Your application must use this information to assign the correct access level.

Use the Veracity ID as the unique user identifier

Use the Veracity ID as the unique user identifier in your application.

The Veracity ID is permanently associated with the user's Veracity account.

Avoid using email addresses as unique identifiers because users can change their email addresses.

If possible, also avoid storing additional user profile data from IDP claims. Instead, retrieve this information from the bearer token issued during login.

This approach helps ensure that profile data remains current and reduces synchronisation issues.

Call the Policy API on every sign-in

Your application must call the Veracity Policy Service API each time a user signs in.

This API enforces important checks:

  • Verifies that the user has accepted the latest Terms and Conditions
  • Confirms that the user has an active subscription for the service on Veracity

For details, see Veracity Policy Service API documentation.

HTTPS and supported browsers

Your application must use the HTTPS protocol.

The application should support the following browsers:

  • Chrome
  • Firefox
  • Edge

If you choose not to support a browser, display a clear warning when users attempt to access the service with that browser. The warning should explain that the application may not function correctly and specify which browsers are supported.