Frequently Asked Questions
We encourage you to create an account directly on Login.gov or an agency partner like USAJobs to see Login.gov in action. Generally a site will place a login button on their site. When the user clicks this button they redirect to Login.gov where they can sign in or create an account. The Login.gov site will be branded with the agency logo and can include help text for migrating existing users. After authenticating with Login.gov they are redirected back to the agency with a unique UUID or email address that identifies the user.
We offer email address and UUID. Since a user can change their email address we recommend tracking users by UUID.
Yes. This is why we recommend using UUID as the primary key.
Every user has a unique UUID per agency for privacy reasons. This means that the same user can return a different UUID depending on which agency they are signing in to. These UUIDs are also globally unique. We do offer sharing of UUIDs between agencies with user consent on a case by case basis.
Once a user is authenticated on Login.gov and passed back to the agency it is up to the agency to manage the user’s session. We do not remotely invalidate or expire a user’s session.
Login.gov makes no guarantees on IP addresses or ranges. Please use the DNS when querying Login.gov for the latest IPs.
Check the error that was returned. Generally we return the specific errors in the HTML, JSON, or in the redirect url.
Feel free to contact the engineers at Login.gov. They can help diagnose your problem further.
No.
No. Login.gov only works via redirects to and from an agency site.
For our Login.gov basic authentication accounts (IAL1), we rely on the user having access to an email address, password, and a secure multi-factor authentication method (AAL2 or higher) such as a phone, authentication app or PIV/CAC where they can receive a secure code to use to sign in to their account.
For identity proofing, in addition to meeting the above requirements for IAL1/AAL2, we ask users to upload a photograph of their state-issued ID and share their address, phone number and other personal information which is then verified against authoritative sources. Login.gov identity proofing services do not meet NIST IAL2 standards at this time. We continue to work toward achieving certification of compliance with the IAL2 standard from a third-party assessment organization.
Login.gov has a public status page available at https://status.login.gov/ where you can subscribe to incident notifications via email, SMS, Slack, or RSS.
Troubleshooting
Login.gov Errors
Background:
For SAML Identity Providers, NameID is the unique identifier used to identify users across multiple sessions. The NameID Format field specifies the format of the NameID field and is defined and/or restricted by the Identity Provider.
This error occurs when Login.gov receives a SAML request with a NameIDPolicy who’se Format field does not match the NameIDFormat specified by Login.gov.
<samlp:NameIDPolicy AllowCreate='true'
Format='urn:oasis:names:tc:SAML:1.1:nameid-format:transient'/>
Solution:
Refer to the Login.gov Developers Guide for the acceptable values for the NameIdFormat SAML field. Update the Login.gov Identity Provider configuration within your Service Provider to specify the correct NameIDFormat field.
For SAML Service Providers, see Other Tips & Tools for help with decoding SAML Requests.
Browser Console Errors
Background:
Content Security Policy (CSP) is a modern web browser defense for Cross-Site Scripting (XSS) attacks. For more information about CSP and XSS attacks, refer to the MDN documentation on CSP.
The CSP form-action directive restricts which URLs can be used as the target of form submissions from a given context. Certain Chromium-based internet browsers (e.g. Google Chrome and Microsoft Edge) enforce the form-action directive through the entire redirect chain (if any). Other non-Chromium-based browsers only check the first redirect in the chain (e.g. Firefox). For Chromium-based browsers, upon form submission, any attempts to redirect to a url not explicitly listed as a form-action source will violate the CSP directive and cause a failure to load and a console error.
This error occurs when Service Providers attempt to redirect users to a url that is not registered in the Redirect URLs field in the Login.gov Dashboard configuration. All urls that users could be redirected to, even as a passthrough, need to be included in the list of Redirect URLs.
Solution:
Use the Network tab of your web browser to identify which redirect (302) is hanging or failing. Add that uri to the list of Redirect URIs in your Login.gov Dashboard configuration.
Other Application Issues
Background:
Any web application that authenticates its users must manage user sessions in order to avoid requiring their users to constantly re-authenticate. Often, this is done using a browser session token that gets passed back and forth between application resources. Session tokens can be valid for variable amounts of time and when they expire, users are required to re-authenticate. Login.gov does not provide a session token for Service Providers as Login.gov is an authentication service, not an authorization service. The authentication token returned from Login.gov is not a session token and should not be used as one.
Solution:
When Service Providers receive a successful authentication response from Login.gov, they should create their own session tokens within their application in order to track their users’ sessions.
Other Tips & Tools
SAML requests from browser consoles are URI encoded, base-64-encoded, and deflate-compressed. Here are steps to obtain a human-readable version of your SAML request.