Alexander Garcia
How we built VA.gov's OAuth 2.0 authentication service, progressively improved it over four years, and finally reached 100% rollout to serve all Veterans nationwide.
Read time is about 26 minutes
Alexander Garcia is an effective JavaScript Engineer who crafts stunning web experiences.
Alexander Garcia is a meticulous Web Architect who creates scalable, maintainable web solutions.
Alexander Garcia is a passionate Software Consultant who develops extendable, fault-tolerant code.
Alexander Garcia is a detail-oriented Web Developer who builds user-friendly websites.
Alexander Garcia is a passionate Lead Software Engineer who builds user-friendly experiences.
Alexander Garcia is a trailblazing UI Engineer who develops pixel-perfect code and design.
Today, December 15th, 2025, we reached 100% rollout of Sign-in Service (SiS). After four years of progressive development, security hardening, stakeholder alignment, and incremental rollouts, VA.gov now has a modern OAuth 2.0 authentication service serving all Veterans and their families. This is the story of how we got here.
Sign-in Service is VA.gov's OAuth 2.0 authentication broker that sits between client applications and credential providers (ID.me and Login.gov). Instead of every VA application implementing their own authentication flows, they integrate with SiS once and get access to all credential providers through a standardized OAuth 2.0 interface.
Think of it as the authentication backbone for the entire VA digital ecosystem.
When I joined the OCTO Identity team in August 2020, VA.gov's authentication landscape was fragmented:
We needed a modern authentication service that could:
Sign-in Service wasn't born from a grand architectural plan. It was born from necessity.
In 2021, we were asked to launch Login.gov as a new credential provider on VA.gov. Login.gov is a government-wide authentication service with strong security credentials and better user experience than legacy options.
We approached the Authenticate Broker team about integrating Login.gov. Their response? "It'll take at least a month."
A month. For one credential provider integration.
This highlighted a fundamental problem: we couldn't move fast because we were dependent on a legacy system and a separate team's bandwidth.
We explored commercial identity integrations:
The math was simple: at 200+ million annual authentications, commercial platforms would cost the VA astronomical amounts each year.
We made a decision: Use the experts on our team to build our own OAuth 2.0 authentication broker.
This gave us:
We built Sign-in Service to support the full OAuth 2.0 Authorization Code flow with PKCE:
/authorize endpoint for initiating authentication/token endpoint for exchanging authorization codes for access tokens/refresh endpoint for refreshing expired tokens/introspect endpoint for validating tokens/revoke endpoint for explicit session terminationMost existing OAuth libraries were not flexible enough to handle multiple authentication brokering systems at the same time. Also the fact that we were locked to Node v14.16.3 also ensure that writing an OAuth 2.0 client-side SDK from scratch was the only approach. We had to ensure all of the following features were created to meet RFC guidelines including:
HttpOnly & anti-CSRF cookies)We built Sign-in Service and launched Login.gov in 2021. The integration took days, not months. More importantly, we now had a modern authentication platform we controlled and we could create additional logging to find performance gaps.
With Sign-in Service proven out with Login.gov, we focused on scaling it across the VA ecosystem.
We built a unified sign-in page that serves as an intermediary for other VA applications:
The sign-in page presents configuration-based credential providers and handles the authentication flow based on the application. Client applications never have to implement authentication logic themselves they just redirect to our sign-in page and authenticate.
This was transformative. Instead of 20 different sign-in experiences, Veterans now see a consistent, polished authentication flow regardless of which VA service they're using.
The VA Health and Benefits mobile app was one of our most challenging and rewarding integrations.
The SAML Problem: Mobile apps and SAML are a terrible combination. SAML relies on browser redirects and cookies, which work poorly in native mobile apps. The mobile team had built workarounds, but they were fragile, complicated and didn't always work as intended leaving many Veterans frustrated.
The OAuth Solution: OAuth 2.0 with PKCE was designed for mobile apps. Create a new configuration and point the VA Health and Benefits app to our Unified Sign-in page that supports:
The migration took exactly one week of coordination, but the results were worth it:
Veterans could now sign in once and have that session work across both the native mobile app and embedded web content. This is the kind of seamless experience users expect, but it's incredibly hard to achieve especially in government systems.
Our Lead Engineer was a Cyber security Expert so we went not only conducted multiple security audits, but also used secure coding best practices by default:
Every audit resulted in improvements:
state validation, and disallowing implicit flowsBy 2024, Sign-in Service was handling millions of authentications. We focused on enterprise features and getting official approval.
We systematically onboarded more VA applications to the Unified Sign-in Page. Each integration followed the same pattern:
client_id and our team configured their redirect URIsNot all VA systems have user interfaces. We have backend services, APIs, batch jobs, and automated systems that need to authenticate with each other.
We built Secure Token Service (STS) for machine-to-machine authentication using Sign-in Service:
This allowed systems without UIs to securely authenticate and access protected resources. Previously, these systems used shared secrets or API keys that were difficult to rotate and manage. Now they use standard OAuth flows with automatic token rotation and secure public/private key certificates. Zero-trust baked right in.
Government systems require Architecture Decision Records (ADRs) for major technical changes. Our ADR needed to document:
The ADR went through multiple review cycles with:
Each review brought new questions, requests for clarification, and sometimes pushback. Government moves slowly by design there's a lot of risk when you're serving Veterans.
The breakthrough came when we reframed the conversation. Instead of "replacing SAML with OAuth," we emphasized:
Veteran benefits:
Risk mitigation:
Future capabilities:
The ADR was approved in mid-2025.
This was a massive milestone. We now had official executive buy-in to make Sign-in Service the primary authentication brokering platform for VA.gov.
With ADR approval in hand, 2025 became the year we fully transitioned to Sign-in Service.
My HealtheVet (MHV) was one of the legacy credentials on VA.gov. It was username/password based and modern security features like multi-factor authentication (MFA) were tied to other IdPs
In March 2025, we removed the My HealtheVet credential. Veterans who previously used MHV credentials were migrated to Login.gov or ID.me, both of which offer stronger security.
This was the first major legacy credential removal a signal that we were serious about modernizing VA authentication.
On July 23rd, 2025, we hit an unexpected roadblock: Oracle Health (formerly Cerner).
The Problem: Oracle Health's integration with VA systems only worked through the SAML-based authentication broker. The Oracle Health team made every effort to migrate from SAML to OAuth but time was ticking to migrate to the modern authentication brokering system.
The Dilemma: We wanted to roll out Sign-in Service to everyone, but Oracle Health users wouldn't be able to access health services. We couldn't strand a subset of Veterans who relied on the VA.
The Solution: The creation of an authentication broker cookie selector system.
Together with my team, I created a cookie-based authentication broker selector that intelligently routes users to the correct authentication broker based on the reading of a cookie. It works by the user authenticating via SAML the first time and we create a long-lived cookie based on if they are an Oracle Health user or not.
This selector allowed us to:
It's not the most elegant solution architecturally, but it was the right pragmatic choice. We could move forward with Sign-in Service rollout without leaving a subset of Veterans stranded.
On December 1st, 2025, we removed the DS Logon credential another legacy username/password credential which was owned and operated by the Department of Defense.
Veterans who used DS Logon were migrated to Login.gov or ID.me. This was another step toward a fully modernized authentication landscape.
Now, VA.gov supports only two modern credential providers:
Both support modern security features: multi-factor authentication, phishing-resistant authenticators, and compliance with NIST 800-63B AAL2.
Today we reached 100% rollout of Sign-in Service.
We didn't flip a switch and go from 0 to 100%. We progressively rolled this feature out to Veterans:
This progressive rollout strategy is critical in government systems. You can't afford to break authentication for millions of users. Each percentage increase gave us data, confidence, and the ability to catch issues before they became catastrophic.
Building a government-scale authentication system taught me lessons you can't learn anywhere else:
Sometimes the best architecture emerges from solving real problems, not upfront designs
In high-visibility systems, slow and steady wins the race
Perfect architecture is the enemy of shipping. Choose the pragmatic solution that moves you forward.
Security isn't a check list. It's a mindset that should inform every architectural decision.
Use government consensus-building to compound targeted progress over time
Never think of a launch as the time to wrap a bow on it. Although Sign-in Service is 100% rolled out to Veterans, it is by no means the end. Instead look at it as a new chapter to create robust, scalable, and useful features for Veterans. Although I'm no longer on the OCTO Identity team I foresee near-term improvements and future capabilities to push the needle forward:
Looking back on five years on the OCTO Identity team at VA.gov, Sign-in Service represents some of my proudest work. Not because it was technically complex (though it was), but because it made a lasting impact to Veterans like myself.
All of these things were enabled by what the OCTO Identity team and myself created. Authentication that "just works"
That's what makes government tech rewarding: the impact at scale.
This work wasn't done alone. The OCTO Identity team includes brilliant engineers, product managers, designers, and security experts who all contributed to Sign-in Service's success. We stood on each other's shoulders. Not to mention a special thanks to our VA stakeholders who championed this work through years of bureaucracy.
And thanks to the Veterans who trust us with their authentication every single day.
Architecture: OAuth 2.0 with PKCE
Credential Providers: ID.me, Login.gov
Client Applications: VA.gov, VA Health & Mobile app, other internal tools
Compliance: NIST 800-63B (AAL1, AAL2)
Scale: 200M+ authentications, 6.9M+ users
Status: 100% rollout as of December 15, 2025
Alexander Garcia served as Lead Frontend Engineer on the OCTO Identity team at VA.gov from August 2020 to October 2025, where he architected Sign-in Service and built authentication infrastructure serving 200M+ authentications for Veterans and their families. He hand-wrote OAuth 2.0 implementations, created custom cryptographic libraries, and helped launch modern credential providers across the VA digital ecosystem.
Hopefully some of you found that useful. Cheers! 🎉