Skip to main content

    Filter by Idea status

    Filter by category

    1017 Ideas

    Add “jti” Claim Support in DocuSign JWT Assertions to Prevent Replay AttacksIdea Submitted

    Idea Description:According to the current DocuSign JWT authentication documentation (https://developers.docusign.com/platform/auth/jwt-get-token/), the supported JWT claims include:{   "iss": "<integration_key>",   "sub": "<user_id>",   "aud": "account-d.docusign.com",   "iat": <epoch_time>,   "exp": <epoch_time+6000>,   "scope": "signature impersonation" } However, the JSON Web Token (JWT) RFC 7519 specification (Section 4.1.7) defines the "jti" (JWT ID) claim, which provides a unique identifier for a token and can be used specifically to prevent replay attacks:“The 'jti' claim can be used to prevent the JWT from being replayed.”The jti value is a case-sensitive string that must be globally unique. While optional in the RFC, it is a widely adopted security enhancement in modern API authentication systems.Why This MattersIn real customer environments, JWT assertions are often passed through multiple layers—load balancers, proxies, middleware, observability layers, or logging systems. When the JWT assertion is URL-encoded and sent to the /token endpoint, these systems may log or store the full request. This creates a risk that the same assertion could be replayed to request a new access token.Given that Docusign manages extremely sensitive business data (contracts, legal records, identity information), strengthening API-level protections is essential. Replay protection is a foundational security mechanism that is often overlooked but has very high impact when compromised.Requested EnhancementPlease consider adding support for the "jti" claim in Docusign JWT validation logic: Allow developers to include a “jti” claim in their JWT assertions Docusign should validate the uniqueness of each jti within a configurable time window. Reject any /token request that attempts to reuse a previous “jti” value Ensures a strong guardrail against replay attacks. Optional logging or monitoring Log replay attempts to help customers detect possible credential leakage. Customer Value Strengthens API authentication security Reduces risk of replay attacks when assertions traverse proxies or logs Aligns Docusign more closely with industry best practices (per RFC 7519) Helps customers meet compliance requirements for high-assurance environments Provides higher protection for mission-critical contract data Builds defense-in-depth for JWT-based integrations With increasing threats in the SaaS ecosystem and the high sensitivity of contract data, adding jti support would be a significant improvement to Docusign’s API security posture. FreeLink/甫连信息🌍 DocuSign Partner | Partner Profile🌟The only DocuSign Partner globally with two Certified eSignature Technical Consultants🏆 DocuSign 2025 APAC Growth  Engine Partner of the Year💡 Ranked #1 in the OG All Star category in DocuSign Community Wrapped 2024📊 DocuSign Community Leaderboard Top 5 contributor🚀 Expertise in DocuSign integrations with on-premises systems for leading enterprises across various industries🔗 Connect with me on LinkedIn: https://www.linkedin.com/in/gehengfeng📬 For business inquiries, feel free to connect via :WeChat/微信: +86 1381880287WhatsApp: +65 97796938

    Provide Long-Lived API-Generated Signing URLs as an Alternative When Email/SMS Delivery FailsIdea Submitted

    Idea Description:Currently, DocuSign supports two signing methods: email-based (remote) signing and embedded signing. Email signing links are valid for 48 hours and can be refreshed by recipients. Embedded signing URLs, however, expire in 5 minutes and cannot be refreshed.Some regions experience frequent issues where recipients are unable to receive DocuSign emails due to domain blocking, SMTP 550 errors, or false-positive spam filtering—often caused by large volumes of emails sent from the customer’s DocuSign account. At the same time, SMS/WhatsApp delivery in certain regions is also unreliable or completely unavailable. These limitations result in recipients being unable to access the signing ceremony at all.To solve this, we propose allowing integrators to generate a longer-lived signing URL via API, similar to the email signing link, that can be manually delivered through alternative channels (corporate messaging apps, internal systems, or verified communication tools).This link can require additional authentication factors—for example: Stronger knowledge-based authentication Additional identity verification before entering the signing ceremony Copy-link consent or audit entry confirming the delivery method Limiting link generation to high-privilege roles or API scopes This ensures signature integrity while providing a practical fallback when email/SMS delivery is not possible.Customer Value: Ensures users can still sign documents when email/SMS channels fail Reduces support cases related to blocked delivery (SMTP 550, spam filters, regional SMS issues) Prevents business delays caused by unreachable signers Increases flexibility for enterprise workflows in regions with strict email filtering Improves overall signer accessibility without compromising security  FreeLink/甫连信息🌍 DocuSign Partner | Partner Profile🌟The only DocuSign Partner globally with two Certified eSignature Technical Consultants🏆 DocuSign 2025 APAC Growth  Engine Partner of the Year💡 Ranked #1 in the OG All Star category in DocuSign Community Wrapped 2024📊 DocuSign Community Leaderboard Top 5 contributor🚀 Expertise in DocuSign integrations with on-premises systems for leading enterprises across various industries🔗 Connect with me on LinkedIn: https://www.linkedin.com/in/gehengfeng📬 For business inquiries, feel free to connect via :WeChat/微信: +86 1381880287WhatsApp: +65 97796938