Skip to main content

Integration examples

  • Updated
 

Login.gov provides authentication and identity verification services to government agencies via standard SAML and OpenID Connect (OIDC) protocols. This article covers common integration patterns, supported platforms, and known compatibility limitations. For step-by-step setup, see the Login.gov developer documentation.

Login.gov does not provide authorization services (user roles, permissions, or access rules). Partners handle authorization on the application side after receiving user attributes from Login.gov. For more on Login.gov's supported platforms, testing and more, see the integration experience article. 

Integration Patterns

There are several ways to integrate with Login.gov, depending on your technical environment and requirements.

Option 1: Direct Integration

The simplest approach is a direct connection between your application and Login.gov using SAML or OIDC.

Figure 1: Direct integration between Login.gov and a partner application

This option works well when:

  • Your technical team can implement SAML or OIDC directly.
  • You follow agile deployment practices.
  • Your application handles its own authorization (roles, permissions, access rules).
  • You want direct control over the integration and the ability to make changes quickly.
  • You need to implement step-up authentication or conditionally specify AAL and IAL levels. Step-up flows for authentication-only integrations are covered in our Authentication guide, and in our Alternative IdV Playbook for Partners (available upon request) for integrations that use our IdV services.

Login.gov provides ODIC sample integration code and SAML sample integration code to demonstrate direct integration. These sample apps are deployed in our sandbox environment (ODIC app, SAML app), and allow you to experience the end-to-end flow from a user perspective. To test your own integration in our sandbox environment, see the testing instructions in the developer documentation.

Option 2: Integration via Identity Platform

Many partners integrate Login.gov through a third-party identity platform that they already use for authorization or other capabilities. Under this pattern the platform communicates with Login.gov via SAML/OIDC and with your application via HTTPS.

Figure 2: Integration via a third-party identity platform

Here is a variation using Azure AD B2C with Power Apps:

Figure 3: Azure AD B2C integration with Login.gov

This option works well when:

  • You need a third party to handle authorization.
  • The third-party platform supports Login.gov’s SAML or OIDC requirements (check the Known Limitations section below).
  • You have many applications that share the same authentication requirements, allowing a single Login.gov integration to serve them all.

Platform-specific articles: 

Several platforms have published integration articles and tutorials, including: 

For additional supported platforms, see the integration experience article. 

Option 3: Enterprise Broker (Single Integration, Multiple Applications)

A variation of the identity platform approach: use an existing ICAM solution or broker service as a single point of integration with Login.gov, then route users to the appropriate application.

Example: A federal government broker service maintains a single integration with Login.gov, but supports multiple end-user applications. When a user visits one of those applications and clicks “Login,” they are redirected to the broker website, which offers Login.gov as a sign-in option. After authentication, the broker redirects the user back to the end-user application where they initiated authentication.

Benefits:

  • Support multiple applications with different requirements (identity verification, phishing-resistant MFA, etc.) through a single Login.gov integration.
  • Authentication and IAL/AAL requirements are specified per-request, so different apps behind the same broker can have different security levels.

Option 4: Integrating with IL4+ DOD Applications

Login.gov is assessed as FedRAMP Moderate and considered IL2 by DOD through existing integrations. For applications at higher impact levels (IL4, IL5), you can place a higher-IL-assessed service between Login.gov and the DOD application.

Option 5: Adding Identity Verification to an Existing Authentication Solution

If you already have an authentication solution but need identity verification for a subset of applications, you can integrate those applications with Login.gov specifically for identity verification.

Specify the required service level in the authentication request. Login.gov supports four service levels, documented in the Integration Overview.

Note: Since Login.gov’s identity verification requires users to authenticate via Login.gov, you would be paying for both authentication and identity verification for those applications. Consider whether consolidating to Login.gov for all applications makes sense.

Email Handling for Broker Integrations

When a broker or identity platform sits between Login.gov and multiple end-user applications, email address handling requires special attention.

Login.gov allows users to associate multiple email addresses with their account. In addition, users can set a preferred email per connected integration, if the integration chooses to support this feature by requesting the singular “email” attribute. This works well for direct integrations but can cause issues with broker setups where different end-user applications require different email addresses.

The solution:

  • Request the "all_emails" attribute, which returns all email addresses on the user’s account. This disables the preferred email feature and allows users to share multiple email addresses with the broker.

For details on requesting attributes, see the User Attributes documentation.

Recommendation:

  • To avoid the email-related issues above, identify users by their UUID rather than email address, since email addresses can change. Use email for initial account linking, then store the UUID for subsequent sign-ins.

Known Platform Limitations

Some third-party platforms have compatibility issues with Login.gov. Review these before selecting a platform.

Microsoft Power Pages

Power Pages only supports the OIDC “implicit flow” with client_secret_post, which Login.gov does not support for security reasons. Login.gov requires private_key_jwt or PKCE.

  • You must use SAML to integrate Power Pages with Login.gov.
  • Power Pages does not support SAML Assertion Encryption (required for production). Login.gov can make an exception for authentication-only applications.
  • If you need identity verification, choose a different platform that supports OIDC or SAML Assertion Encryption.

See: Login.gov OIDC Getting Started | Power Pages OIDC docs | Power Pages SAML docs

Microsoft Entra External ID

Entra External ID cannot currently integrate with Login.gov. It does not allow setting the OIDC “acr_values” parameter (required by Login.gov), and does not allow customizing required SAML parameters.

SiteMinder

SiteMinder does not appear to support OIDC the way Login.gov requires. Several partners have been unable to get OIDC working with SiteMinder. Use SAML instead.

Cloudflare Zero Trust

Cloudflare Zero Trust is not compatible with Login.gov. It does not support SAML Assertion Encryption or private_key_jwt for OIDC.

SAML with Broker + Multiple Subdomains

If you use SAML with a single broker integration and your end-user applications are on different subdomains or domains, each subdomain must be registered in the Partner Portal as an additional redirect URI.

This creates two problems:

  • Manual effort to register and maintain hundreds of URIs.
  • CSP (Content Security Policy) headers have a size limit (~8KB). Login.gov adds registered URIs to CSP headers; too many can exceed this limit and block redirects in most browsers.

Current workaround:

  • Use OIDC instead of SAML. OIDC redirects use an interstitial page with a JavaScript-triggered link rather than a form POST, so only the broker’s redirect URI needs to be registered. Subsequent redirects from the broker to applications don’t require CSP entries.

Okta

Okta for DoD (approved for IL4/IL5) can sit between Login.gov and a DOD application. Login.gov only interacts directly with the Okta for DoD service.

Troubleshooting and Support

For additional troubleshooting tips, see the developer support documentation. For general integration guidance including sandbox setup, testing, session behavior, and change management, see the integration experience article.