Frequently Asked Questions (FAQ)
General
Login.gov has over 50 partners including federal, state, and local government agencies. Our product is integrated with over 500 applications.
As of October 2024, Login.gov has over 100 million user accounts with more than 300 million sign-ins annually.
Login.gov is not a standalone federal agency. We are a program of the General Services Administration (GSA), an agency of the U.S. federal government. The program is run by the Technology Transformation Services (TTS), a group that leads the digital transformation of the federal government by helping agencies build, buy, and share technology that allows them to provide more accessible, efficient, and effective products and services for the American people.
Yes, Login.gov partners with state, local, and territory governments. These government entities need simple and secure solutions to help the public access services and resources, and with this partnership, they can leverage Login.gov to create a seamless and secure sign-in experience for the public to access these services and resources. Learn more about the path to partnership
Contact our Partnerships Team to get started. We’ll work with you to understand and capture your needs and requirements at a high level. Together, we’ll decide whether Login.gov makes sense for your particular agency and use case. If we decide to move forward, the next step is to sign an Interagency Agreement (IAA). This signals a mutual commitment which allows us to commit further resources to technical discovery and integration and migration planning.
Logistics
An Interagency Agreement (IAA) is a type of contract. Login.gov is a cost-recoverable federal service, which means we must, by law, charge other agencies for our work. Our partnership and financial engagement will be governed by the IAA.
Login.gov does not provide authorization. At this time, Login.gov supports authentication and identity verification capabilities. We encourage agencies to take the lead on determining the best strategy for their role management and authorization.
“Identity proofing is the process by which a CSP (credentialing service provider) collects, validates, and verifies information about a person.” - NIST SP 800-63-3, Digital Identity Guidelines
This is the process Login.gov uses to verify that a user is who they say they are. While many agencies can validate an individual’s identity through an in-person proofing experience, we developed an online application that allows individuals to have their identities verified from their smartphone or computer.
Non-U.S. citizens and non-U.S. immigrants can authenticate with Login.gov, though select features (e.g., SMS / voice OTC for MFA) may be restricted in certain countries. Check our International phone number support for a complete list that Login.gov supports for authenticating end-users.
Non-U.S. citizens and non-U.S. immigrants can verify their identity (i.e., “proof”) with Login.gov as long as they have a valid U.S. state-issued ID, Social Security number (SSN), and U.S. address.
At this time, only the following state-issued identification is accepted:
- Driver’s license from all 50 states, the District of Columbia (DC), and other U.S. territories (American Samoa, Guam, U.S. Virgin Islands, Mariana Islands and Puerto Rico)
- A non-driver’s license state-issued ID card
- This is an identity document issued by the state/U.S. territory that asserts identity but does not give driving privileges.
Users cannot verify their identity on Login.gov without a state-issued ID. We’re currently working to add more ways to verify identity. Learn more about the requirements for verifying identity
Development
Login.gov provides an open sandbox environment to create and test integrations between Login.gov and your applications. In the sandbox environment, we provide a Dashboard where you can manage your test applications. Visit the Developer guide to get started with our sandbox.
An authentication is counted every time the user enters their username/password and is successfully redirected back to a given application.
Check Production deployment for more details. We deploy changes to our production configuration on Tuesday and Thursday by the close of the business day. If regular deployment is scheduled for a holiday then it will be completed on an alternate day.
We do not support the OpenID Connect “implicit flow” with client_secret because it is not recommended by the OAuth group for security reasons. We do support OpenID Connect private_key_jwt and PKCE.
For more info see:
In order to launch your integration with Login.gov, your agency must first complete an IAA. You can test your application during the IAA process. Once testing is complete and the IAA has been executed, Login.gov aims to launch your integration within two weeks. We recommend a grace period between deployment of your Login.gov configuration and implementation on your site. Learn more about our IAA process
Login.gov supports any platform that uses either the SAML or OpenID Connect (OIDC) protocol.
Yes, partners can configure an app to restrict MFA using one of these options:
- Users can choose any MFA option supported by Login.gov;
- Users must sign in with a phishing-resistant MFA option. Login.gov supports the following phishing-resistant options: Face/touch unlock, security key (such as yubikeys), and PIV/CAC cards; or
- Users must sign in with a PIV/CAC card.
The default setting can be configured per application on the partner dashboard, and it can be overridden on a per-request basis.
To override the default setting, or to set it within the authentication request, please refer to our developer documentation, under the “Authentication Assurance (AAL) Values” dropdown.
For OIDC: https://developers.login.gov/oidc/authorization/
For SAML: https://developers.login.gov/saml/authentication/
Login.gov can help agencies implement specific controls described in OMB M-22-09, which provides guidance on the “Zero-Trust” Executive Order. According to that memo, agencies must use strong MFA throughout their enterprise:
- MFA must be enforced at the application layer, instead of the network layer.
- Phishing-resistant MFA is required for agency staff, contractors, and partners.
- For public users, phishing-resistant MFA must be an option.
- Password policies must not require use of special characters or regular rotation.
Login.gov’s implementation supports these needs in the following ways:
- For agency applications: Login.gov supports an authentication request that requires a user to authenticate with a phishing-resistant MFA supported by Login.gov–such as face/touch unlock, security key, or PIV/CAC card.
- For public applications: By default, Login.gov provides phishing-resistant MFA as an option.
- Login.gov password policies meet the latest guidelines as per NIST 800-63B 5.1.1.2, including the requirements mentioned in OMB M-22-09.