Skip to main content
U.S. flag

An official website of the United States government

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock ( Https ) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Integration overview and user flow

Login.gov is a FedRAMP moderate approved multifactor authentication and identity proofing platform that makes online interactions with the U.S. government simple, efficient and intuitive.

User flow

A diagram flow of IAL1 walkthrough experience
Fig. 1: Authentication flow
  • Once you have successfully integrated your application with the Login.gov environment, users start at your application and are redirected back to Login.gov via OpenID Connect (OIDC) or SAML protocols.
  • The service level you specify via the authentication request sent by your application will determine the type of verification required for the user’s account. Identity proofed accounts require the user to complete additional steps to verify their identity in addition to the Multifactor Authentication (MFA).
  • New users will create an account corresponding to the identity assurance level requested. Returning users will present their existing Login.gov credentials to authenticate with Login.gov. A new user to your application will consent to their information being shared with your application upon creating an account.
  • Upon successful completion of the account creation and authentication, users will be redirected back to your application with the user attributes that correspond to their user level.
  • With the attributes provided by Login.gov, your application will handle authorization of the user and assign roles and permissions.

Service provider configuration

This is the configuration for your application within Login.gov’s identity provider. In the sandbox environment, you will be able to determine the configuration yourself and decide what is the best fit for your needs. In the Login.gov production environment, we will manage the final configuration.
To configure a test application in the sandbox environment:

  • Create an account in the Partner Portal. From here you will be able to test various configurations and determine what is right for your agency.
  • Select between OIDC or SAML protocol implementation protocols and understand which user attributes are required.
  • If you have questions when testing your integration, read through our FAQs or submit a ticket to our technical support help desk.
  • Before submitting a request to move your application’s configuration to production, review the User experience page and the Production page. Additional requirements, like a signed Interagency agreement (IAA) and agency logo, are described in these pages.

Service Levels

Service Level, or Identity Assurance Level, determines what information is used to confirm a user’s identity.

A type of service level must be specified.

  • urn:acr.login.gov:auth-only
    Requires basic identity assurance: email address, password, and at least one MFA method. No identity verification.

    Meets either NIST 800-63-3 AAL1 or AAL2 standard (depending on agency integration configuration)

  • urn:acr.login.gov:verified
    Requires that the user has gone through basic identity verification without facial matching.

    Does not meet NIST 800-63-3 IAL2 standard.

  • urn:acr.login.gov:verified-facial-match-required
    Requires identity verification with facial match for all users. Even if a user has been previously verified without facial matching, they will be required to go through verification with facial match.

    Meets NIST 800-63-3 IAL2 standard.

  • urn:acr.login.gov:verified-facial-match-preferred
    Requires identity verification. Users with no previous identity verification will be required to go through a facial match. Users with previous identity verification will use that data, even if it was done without facial match.

    Authentications for users who verify with facial matching will meet NIST 800-63-3 IAL2 standard. Authentication for users who do not do facial matching will not meet NIST 800-63-3 IAL2 standard.

Authentication Assurance Levels

Authentication Assurance Level determines what second factors are allowed for user sign-in.

We default to requiring a user to be authenticated with a second factor:

  • urn:gov:gsa:ac:classes:sp:PasswordProtectedTransport:duo
    This specifies that a user has been authenticated with a second factor. This value will be returned in the user attributes by default. We do not allow strict AAL1, because it implies that a user did not authenticate with a second factor. This setting requires users to reauthenticate with a separate second factor (i.e. not a remembered device) once every 30 days at a minimum.

Stricter behavior can be specified by adding one of:

  • http://idmanagement.gov/ns/assurance/aal/2
    This is the same as the default behavior except users must authenticate with a separate second factor (i.e. not a remembered device).
  • http://idmanagement.gov/ns/assurance/aal/2?phishing_resistant=true
    This specifies that a user has been authenticated with a cryptographically secure method. We currently support security keys, face or touch unlock, and PIV/CAC. Users must always authenticate with a second factor.
  • http://idmanagement.gov/ns/assurance/aal/2?hspd12=true
    This specifies that a user has been authenticated with an HSPD12 credential (requires PIV/CAC). Users must always authenticate with a second factor.
Edit this page
Return to top