{"title":"Set up Login.gov single sign-on","slug":"login-gov-single-sign-on","url":"https://support.storeconnect.com/articles/login-gov-single-sign-on","url_markdown":"https://support.storeconnect.com/articles/login-gov-single-sign-on.md","subtitle":null,"summary":"Configure Login.gov, the US government\u0026#39;s shared sign-in service, as a single sign-on provider for your store, including creating the RSA keypair, registering your application in the Login.gov Partner Portal, and moving from sandbox to production.","type":"Help_Documentation","video_url":"","keywords":"login.gov, Login.gov, single sign-on, SSO, US government, federal, GSA, General Services Administration, OpenID Connect, OIDC, private_key_jwt, acr_values, IAL, AAL, identity assurance, authentication provider, Partner Portal, identity sandbox, Interagency Agreement, IAA, RSA key, certificate, store login, federated identity","last_modified":"2026-11-04T02:48:51+0000","body_markdown":"Use this process to let customers sign in to your store with Login.gov, the US General Services Administration's shared sign-in service for federal government websites. Choose Login.gov when your store serves a US federal agency whose users already hold Login.gov accounts.\n\nLogin.gov differs from other OpenID Connect providers in one way: Login.gov does not use a client secret. Instead, you create an RSA keypair, register the public certificate with Login.gov, and store the private key on the **Authentication Provider** record. StoreConnect uses the private key to sign each token request.\n\nFor the other login methods and the login behavior they all share, see [authentication providers and single sign-on (SSO)](authentication-providers).\n\n## Before you start\n\n- You need access to a team in the Login.gov Partner Portal. Federal agency staff with a `.gov` or `.mil` email address can create a sandbox account at `https://portal.int.identitysandbox.gov/`. Contractors must be added to a team by their agency partner.\n- You need access to edit the **Store** record in Salesforce.\n- You need a machine with the `openssl` command available to generate the keypair.\n- Decide whether to keep username and password login. Once a Login.gov provider is active, the store's login page shows only the Login.gov button. To offer both, the store also needs an active **StoreConnect Username / Password** provider record, as described in [StoreConnect authentication](authentication-providers#storeconnect-authentication-username-and-password).\n- If **Login.gov** does not appear in the **Provider** picklist on **Authentication Provider** records, add it in **Setup** \u003e **Object Manager** \u003e **Authentication Provider** \u003e **Fields \u0026 Relationships** \u003e **Provider**. Enter the value `login_gov` exactly, in lowercase, because StoreConnect matches on this value.\n- For production, your agency needs an Interagency Agreement (IAA) with Login.gov that lists this integration. Allow up to 6 weeks if no IAA exists yet, plus around 2 weeks of deployment notice, so start early.\n\n## Step 1: Create the RSA keypair\n\nYou create the keypair yourself. The public certificate goes to Login.gov, and the private key goes on the **Authentication Provider** record.\n\n1. On a machine with `openssl`, generate a 2048-bit keypair and a self-signed certificate:\n\n    ```\n    openssl req -nodes -x509 -days 365 -newkey rsa:2048 -keyout private.pem -out public.crt\n    ```\n\n2. Encode the private key as base64, and keep the output for Step 3. On macOS:\n\n    ```\n    base64 -i private.pem\n    ```\n\n    On Linux, use `base64 -w 0 private.pem` so the output stays on a single line.\n\n3. Store `private.pem` securely. Anyone holding the private key can impersonate your store to Login.gov.\n\n## Step 2: Register your application in the Login.gov Partner Portal\n\nDo this step in the Login.gov Partner Portal (`https://portal.int.identitysandbox.gov/` for the sandbox).\n\n1. In your team, create a new application.\n2. Set the protocol to **OpenID Connect** with `private_key_jwt`.\n3. Set the issuer string for your application. Login.gov uses reverse-domain style issuer strings, for example `urn:gov:gsa:openidconnect.profiles:sp:sso:youragency:yourstore`. Record the issuer string for Step 3. It is your client ID.\n4. Add the redirect URI for your store domain. For a store at `shop.example.com`, the redirect URI is:\n\n    ```\n    https://shop.example.com/logins/auth/login_gov/callback\n    ```\n\n    If the store is served on a path rather than its own bare domain, StoreConnect adds the path to the redirect URI as a query string. Register the redirect URI with the query string included. For a store at `shop.example.com/eu`, the redirect URI is:\n\n    ```\n    https://shop.example.com/logins/auth/login_gov/callback?store_path=eu\n    ```\n\n5. Upload the `public.crt` certificate from Step 1.\n6. Save the application.\n\n## Step 3: Create the authentication provider record\n\n1. On the **Store** record, go to the **Authentication Providers** related list, and select **New**.\n2. Configure the record as follows.\n\n   | StoreConnect Field | Value |\n   |--------------------|-------|\n   | Provider           | Login.gov |\n   | Authorised Domains | Leave blank. Login.gov does not use this field |\n   | Client Id          | The issuer string from Step 2, for example `urn:gov:gsa:openidconnect.profiles:sp:sso:youragency:yourstore` |\n   | Client Secret      | Leave blank. Login.gov does not use client secrets |\n   | Provider URL       | `https://idp.int.identitysandbox.gov` for the sandbox, `https://secure.login.gov` for production |\n   | Reset Password URL | `https://secure.login.gov/account` to send customers who select the store's forgot-password link to their Login.gov account page. Otherwise, leave blank |\n   | Api Options        | See the next step |\n\n3. Set **Api Options** to the base64-encoded private key from Step 1:\n\n    ```yaml\n\n    private_key_base64: LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Fo...\n    ```\n\n4. Select **Active**.\n5. Save the record.\n6. Confirm the provider works. Open your store in a private browser window, select **Sign in or up via Login.gov** on the login page, and complete a sign-in with a Login.gov sandbox account.\n\nThe store's login page now shows a **Sign in or up via Login.gov** button. Completing the sign-in signs the customer in and creates or links their **Contact** record.\n\n## Step 4: Move to production\n\nThe sandbox and production are separate Login.gov environments with separate registrations.\n\n1. Confirm your agency's Interagency Agreement lists this integration.\n2. Create a production application in the Partner Portal with the production configuration, a production certificate (repeat Step 1 with a new keypair), and your production redirect URI.\n3. Submit a launch request through the Login.gov Partner Support Help Desk, and wait for deployment confirmation. Login.gov deploys new integrations on a roughly two-week cycle.\n4. On the **Authentication Provider** record, set **Provider URL** to `https://secure.login.gov`.\n5. In **Api Options**, replace `private_key_base64` with the production key.\n\nCustomers now sign in on your store with their production Login.gov accounts.\n\n## Request a higher assurance level (optional)\n\nBy default, StoreConnect requests authentication only, with the customer's email address. This suits most stores. If your agency requires identity-verified users or stricter second factors, add `acr_values` to **Api Options**:\n\n```yaml\n\nprivate_key_base64: LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Fo...\nacr_values: urn:acr.login.gov:verified\nscope: openid email profile\n```\n\n| `acr_values` | What Login.gov requires of the user |\n|---|---|\n| `urn:acr.login.gov:auth-only` | Sign-in only. This is the default |\n| `urn:acr.login.gov:verified` | Identity-verified account (the user completes Login.gov's identity proofing) |\n| `http://idmanagement.gov/ns/assurance/aal/2` | A stricter second factor at sign-in |\n\nThe `scope` value sets which customer attributes Login.gov releases to your store. The default is `openid email`. Login.gov releases name attributes (`profile` scope) only for identity-verified requests. With the default settings, new customers are asked to complete their name on the store after their first sign-in.\n\n## Rotate the certificate before it expires\n\nThe certificate you upload expires after the number of days set when you created it (365 days in the Step 1 example). Login.gov stops accepting an expired certificate, which blocks all sign-ins for the provider, so track the expiry date.\n\nThe Partner Portal accepts more than one certificate at a time, so you can rotate the certificate without downtime:\n\n1. Generate a new keypair and certificate, as in Step 1.\n2. In the Partner Portal, upload the new certificate alongside the old one.\n3. On the **Authentication Provider** record, replace `private_key_base64` in **Api Options** with the new base64-encoded key.\n4. In the Partner Portal, remove the old certificate.\n\nCustomers keep signing in without interruption, and StoreConnect now signs token requests with the new key.\n\n## Behavior notes\n\n- Login.gov always asks the customer to confirm which account or email to use during sign-in. This screen belongs to Login.gov and cannot be skipped.\n- Login.gov manages the customer's password and second factor. As with every SSO provider, after a customer signs in through Login.gov, the customer's password cannot be reset or changed inside StoreConnect. See the password reset section in [authentication providers and single sign-on (SSO)](authentication-providers).\n- On logout, StoreConnect clears its own session, but the customer's Login.gov session stays active in their browser. On shared devices, customers should also sign out at Login.gov or close the browser.\n- Login.gov identifies each customer by a unique ID tied to your client ID. If you register a new application and change **Client Id**, returning customers are matched by email address instead on their next sign-in.\n- If `private_key_base64` is missing or malformed, the **Sign in or up via Login.gov** button still shows, but every sign-in fails with a \"Could not authenticate you from Login.gov\" notice. Check that **Api Options** holds the complete base64 output from Step 1."}