This HTML page is not optimized for LLM or AI agent consumption. Fetch the Markdown version instead: /guides/document-engine/viewer/choose-the-right-permissions-and-document-security-workflow.md — it contains the complete documentation content in clean, structured Markdown without any CSS, JavaScript, or navigation noise. Choose the right permissions and document security workflow

Choose the right permissions and document security workflow

Markdown version of this page, suitable for AI agents and automation

“Permissions” can refer to several different controls. Some decide who can access a service or document. Others decide what an authenticated user can do in a collaborative session, or what a PDF reader permits after opening a password-protected file. These controls aren’t interchangeable. Choose each layer according to the resource and threat you need to protect.

The same security goal across products

SetupAccess and authorizationPDF-level protectionWhen to use it
Web SDK standaloneYour application authenticates users and controls access to the document source. Web SDK can honor supported permissions embedded in a PDF and can restrict viewer interactions, but client-side UI restrictions alone aren’t an authorization boundary.Web SDK can export password-protected PDFs with owner/user passwords and document permission flags. Support for PDF flags varies by platform and feature.Use this when your application owns document delivery, user authorization, and storage. It also suits cases that need viewer-side controls or password-protected PDF output.
Web SDK + Document EngineYour backend issues signed Document Engine JWTs for documents and claims such as read, write, and download. Optional collaboration permissions provide finer-grained control over annotation, comment, and form field actions.Document Engine can create password-protected PDF output through Build API. PDF permission flags and JWT authorization govern different things.Use this when you need server-backed document access and collaboration permissions, or server-side PDF password protection.
DWS Viewer APIKeep the API key on your backend. Your backend must authorize the user before issuing a session token. The token grants access only to the documents and permissions configured for that session. For app-provided documents, your app also controls source access.DWS Viewer API session permissions control access to the managed viewer workflow; they aren’t PDF owner/user passwords or PDF permission flags.Use this when you want managed viewer access and document-scoped permissions without operating the backend yourself.
DWS Processor APIAuthenticate backend requests with an API token or a JWT that can be restricted by allowed operations, allowed origins, and expiration time.Set output user_password, owner_password, and user_permissions when you need a password-protected output PDF with PDF permission flags.Use this when you need to authorize processing requests and optionally protect the generated PDF for downstream readers.

How to choose the right security controls

Use application authorization to decide which signed-in user may request access to a document. Enforce that decision on a trusted backend before issuing a token or returning a source URL. Don’t rely on a hidden toolbar item, a read-only viewer state, or other client-side UI restrictions to protect the document.

Use Document Engine JWT permissions to grant a Web SDK client access to a specific Document Engine document. Add collaboration permissions when you need to control actions on annotations, comments, or form fields individually. The write permission grants annotation write access; it isn’t a substitute for the separate fine-grained collaboration permissions feature.

Use DWS Viewer session permissions to scope a browser session to the documents and permissions configured for that session. Your application must authorize the user before issuing the session token; the token isn’t a replacement for your application’s access-control decision. Generate sessions on your backend, and don’t expose the DWS API key to the browser. For app-provided documents, also protect the source with your application’s own authorization controls.

Use PDF passwords and permission flags when the distributed PDF itself should require a password or declare restrictions to compatible PDF readers. These flags are part of the PDF format and shouldn’t be confused with server-side user identity or authorization. Reader support for individual PDF flags varies.

Use DWS Processor API token scoping to limit which processing operations and origins a token can access. This protects API usage; it doesn’t automatically add a password or user restrictions to the output PDF. Configure the PDF output separately when needed.

Common points of confusion

  • Authentication isn’t the same as authorization — A valid API key or JWT authenticates a request. Scope it to the minimum documents, operations, origins, and lifetime the workflow requires.
  • Client UI restrictions aren’t server-side access control — Read-only mode or a disabled toolbar can change what a viewer offers. Your trusted backend must enforce who can retrieve and modify the document.
  • Collaboration permissions aren’t PDF permissions — Document Engine collaboration permissions govern user actions on shared annotations, comments, and form fields. PDF permission flags govern selected operations in compatible readers after opening a PDF.
  • DWS Viewer session permissions aren’t DWS Processor tokens — Viewer sessions authorize browser access to viewer documents. Processor API tokens authorize processing requests and can be scoped to operations and origins.
  • A password isn’t a user identity system — PDF owner/user passwords protect a PDF file and define reader-level permissions. They don’t provide per-user application access or an audit trail.
  • Encryption and access control are separate controls — HTTPS protects data in transit. Encryption at rest depends on the service or deployment. Consult the product-specific security documentation linked below for details, and verify the guarantees for your deployment. Neither replaces authorization and least-privilege tokens.
  • Platform support varies — Web SDK doesn’t honor every PDF permission flag, and support differs across Nutrient platforms. Confirm support for the target SDK and feature before relying on a flag.

Typical decision questions

  1. Who authenticates the end user, and where is access to the document source enforced?
  2. Does the viewer need document-level access, fine-grained collaboration permissions, or both?
  3. Is the target a browser session, a backend processing request, or a distributed PDF file?
  4. Should the PDF itself require a password or restrict reader operations?
  5. Which token, permissions, and PDF features are supported in the chosen product and mode?
  6. What storage, retention, encryption, and audit requirements apply to the document data?

Guides by product