SSO Integration: Google and Microsoft Sign-In for Rebate Portals

Why SSO Matters for Rebate Programs

Rebate applications have a friction problem. A homeowner wants to claim their heat pump rebate, but first they need to create an account, verify their email, and remember yet another password. Many abandon the process. Those who complete it often forget their credentials when they return to check their rebate status.

For program administrators and contractors, the problem is different. They're already signed into their organization's Microsoft account all day. Asking them to maintain a separate password for the rebate portal is both inconvenient and a security risk — people reuse passwords or write them down.

We addressed both scenarios:

• Social login (Google, Microsoft personal) for public rebate portals — homeowners and small contractors can sign in with accounts they already have
• Enterprise SSO (Microsoft Entra ID) for back-office users — larger organizations authenticate through their existing identity provider

The Architecture

We built a dedicated identity service that handles all authentication flows. The rebate portal and admin application remain stateless — they redirect to the identity service for authentication and receive a token back.

Social Login Flow

1. User clicks "Sign in with Google" on the claims portal
2. Portal redirects to our identity service with a return URL
3. Identity service initiates OAuth with Google/Microsoft
4. User authenticates with their provider
5. Provider redirects back to our identity service with user info
6. Identity service generates an HMAC token and redirects to the claims portal with email, name, and token
7. Claims portal verifies the token and creates or links the user account

The HMAC token prevents tampering — the claims portal can verify the redirect came from our identity service, not a spoofed request.

Enterprise SSO Flow

For organizations with Microsoft Entra ID (formerly Azure AD), the flow is similar but includes tenant verification:

1. User navigates to their organization's branded login page (e.g., /sso/login/acme-energy)
2. Page displays the organization's logo and a "Sign in with Microsoft" button
3. Identity service initiates OpenID Connect with Microsoft
4. User authenticates through their organization's Microsoft account
5. Identity service verifies the email exists in that tenant's user directory
6. If found, generates a login token and redirects to the admin application

The key difference: we verify the user belongs to the specific tenant they're trying to access. An employee of Acme Energy can't accidentally (or intentionally) access Beta Utility's portal just because they have a Microsoft account.

Multi-Tenant Considerations

Our platform serves multiple organizations from the same infrastructure. SSO adds complexity here:

Tenant-specific branding. Each organization's login page shows their logo and name. This builds trust — users know they're signing into their organization's system, not a generic page.

Per-tenant SSO toggles. Some organizations want SSO, others don't. Some want Google login for their public portal but not Microsoft, or vice versa. We added per-site configuration flags so each tenant controls which authentication methods are available.

User matching. When a user signs in via SSO, we match by email address. This works well for enterprise SSO where email domains are controlled. For social login, we allow linking — a user who previously registered with a password can connect their Google account and use either method going forward.

Security Details

A few things we got right:

Issuer validation. For enterprise SSO, we use Microsoft's "common" endpoint to allow any organization. But we don't blindly trust the issuer — we verify the authenticated email exists in our database for that specific tenant.

Token expiration. Login tokens are single-use and expire quickly (minutes, not hours). The actual session is managed by the application, not the identity service.

No password fallback for SSO tenants. Organizations that enable enterprise SSO can disable password authentication entirely. This prevents the "I forgot my SSO password" support ticket that makes no sense.

Secure cookies. State cookies (return URL, tenant slug) are HttpOnly, secure in production, and short-lived. They can't be read by JavaScript or transmitted over unencrypted connections.

The Developer Experience

Adding SSO to a new application is straightforward:

1. Redirect to /b2c/challenge/{provider}?returnUrl=... for social login
2. Handle the callback with email, name, provider, and verification token
3. Verify the token matches the expected HMAC
4. Create or link the user account

For enterprise SSO, tenants get a branded URL they can bookmark or add to their internal portal. No configuration needed on their end — they just click and authenticate.

Results

Since launching SSO:

• Password reset requests dropped significantly — users who sign in with Google don't have a password to forget
• Application completion rates improved — fewer users abandon at the "create account" step
• Support tickets about login issues decreased — "Sign in with Microsoft" is hard to get wrong
• Enterprise clients are happier — their users never leave their organization's identity ecosystem

What's Next

We're working on:

• Apple Sign-In for the mobile app
• SAML support for organizations that don't use Microsoft Entra ID
• Passkeys for passwordless authentication without relying on third-party providers

The identity service architecture makes these additions straightforward — each new provider is another OAuth/OIDC integration that returns the same email and name to the calling application.

Authentication is infrastructure. The less users think about it, the better we've done our job.