Hi everyone 
I hope it’s okay to share this here alongside the discussion. I’m also a GSoC 2026 applicant, currently working on the OAuth 2.0 (Outlook SMTP) support for the email-ext plugin.
I’ve been exploring the plugin’s authentication flow, SMTP configuration, and overall architecture to better understand where OAuth integration would fit securely and cleanly.
Earlier, I had shared a possible solution direction, but based on guidance from a Jenkins community member, I’ve intentionally avoided developing it further, as it was advised to keep such implementations within the GSoC process.
Since then, I’ve focused on refining my proposal, studying the codebase, and aligning my approach with secure token handling, extensibility, and real-world usage scenarios.
I’ve documented my proposal and exploration here:
GSoC2026_Jenkins_OAuth_Proposal_FINAL.docx - Google Docs
If mentors or community members have any last-minute suggestions or feedback before submission, I’d really appreciate it.
Thanks for all the valuable discussions in the community — they’ve been really helpful 
Looking forward to contributing! 
OAuth Integration Architecture for Jenkins email-ext Plugin
OAuth 2.0 Token Retrieval and SMTP Authentication Flow
Separation of Responsibilities: email-ext Plugin vs entra-oauth-plugin
Separation of Responsibilities: email-ext Plugin vs entra-oauth-plugin
Hi mentors,
While refining my proposal, I spent more time analyzing the current XOAUTH2 implementation and its interaction with Jenkins’ credential system.
One key realization I had is that the issue is not just about “adding OAuth support,” but about maintaining proper separation of responsibilities within the Jenkins plugin ecosystem.
The email-ext plugin currently exposes XOAUTH2, but without integrating with a credential provider that can supply a valid access token at runtime, the implementation becomes misleading rather than functional.
This made me rethink the design from a system perspective — instead of embedding token logic, delegating authentication entirely to entra-oauth-plugin via EntraOAuthCredentials.getAccessToken() ensures:
• Correct OAuth flow handling (token, refresh, expiry)
• Alignment with Jenkins credential management patterns
• Avoidance of duplicated token lifecycle logic inside email-ext
This also makes the solution extensible for future providers without modifying the core email-ext authentication flow.
Would appreciate any thoughts on whether this interpretation aligns with the intended architectural direction.
