Investigate authentication issues between Login.gov and Notify.gov

[ccostino]

We've run into a few issues when testing the sign-in process locally where users won't be authenticated into Notify.gov even after successfully signing in with Login.gov, and/or they are difficulties signing in because multiple existing Notify.gov accounts are tied to the same Login.gov account or vice versa.

We need to understand what is happening and where any breakdowns in the sign-in flow are happening so we have a clear picture of what we need to address and fix.

What we know so far

To date, we've seen the following issues:

• A user tries to sign into Notify.gov via Login.gov, first creating a new Login.gov account. The user goes through the email validation steps, and then signs in successfully with Login.gov. This account is mapped 1:1 between the two services; they sign in successfully in Login.gov, but are redirected back to the page waiting for the email to be validated with Login.gov, and are stuck.
  • Under the hood, it appears that the check for if the user is authenticated is returning False and/or the user is detected as also being signed in to another device.
  • It's unclear why these two things are the case right now.
• A user tries to sign in to Notify.gov via Login.gov with an account in Login.gov that may be tied to multiple existing Notify.gov accounts.
  • We need to understand how this situation can occur in the first place, which means to trying to recreate the scenario.
  • One known situation is a user accepts an invite, signs in to Login.gov with a secondary email on it and the wrong email is passed to Notify.gov, which causes a new Notify.gov account to be created in the process that is both tied to the wrong email address and shared with a single Login.gov account.
  • One thing to follow-up with Login.gov support on: can we only get the primary email on the account, or default to receiving it? When and why would we receive only the secondary email?
• The sign-in flow within the admin appears to work and perform all of the correct checks and actions, and receives the necessary information back from Login.gov, but the API is returning 403s when passed the data to find and authenticate the user, contributing to some of the breakdowns listed above and in turn causing the admin to return 401s to the client (browser).
  • It's unclear why when all of the information is present and appears to be correct, and Login.gov is indicating a valid user, the API cannot authenticate them properly; this will require stepping through the authentication process in the sign-in flow.
• A production user has reported a similar issue of not being able to sign in after the Login.gov switch, and after we've fixed the case sensitivity checking with emails.
  • The last known attempt was at 1:38 PM PT / 4:38 PM ET on 4/30/2024, so we can check our production logs for any signs of errors and such.

We also know of two other things that need to be addressed, which are already tracked in separate issues:

• The code for checking that a user is only able to accept an invite for themselves needs to be wired back up.
  • @terrazoon is tackling this with Refactor the remaining pieces of the sign-in process #1459 already.
• We need to restrict to *.gov and *.gov-adjacent emails only: Bug: non-.gov emails are allowed to register #1481

Implementation Sketch and Acceptance Criteria

• Research each of the known issues listed above and see if there's a common thread between them or if they are truly different from each other and need to be addressed separately.
  • If they're separate in any way, we'll write individual issues for those pieces of work.
• Based on the research, write-up findings and propose an approach or approaches to address the issues we're seeing; we'll discuss those as a team to determine our next course of action(s) and make sure we have a full and clear picture of everything.

Security Considerations

• We need to make sure our sign-in process is working properly so we don't have unauthorized access to the system.
• We need to make sure we're interacting with Login.gov correctly and that we don't have any missing or incorrect steps in the process.
• We need to make sure user accounts are being properly created and updated in the Notify.gov side.

[terrazoon]

What are *.gov adjacent emails?

[ccostino]

Ah, good question! Things that are official government emails but not with the *.gov domain. *.mil and *.si.edu are the most common examples. You can see the full details and lists here! https://github.com/GSA/govt-urls

[terrazoon]

At this time we think all the login issues were caused by Notify thinking the user was logged into two devices at the same time. We don't know why that was a restriction, and we don't know why Notify is wrong about it (Andrew in his case was not logged in to two devices).

There are some tickets for other defined login.gov cleanup issues like checking if the email used is a government email address, but at this time we don't think users are locked out for mysterious reasons (unless we get some reports that they are, since our fix for the original problem is up on production now).

[ecayer]

We (@ccostino and I) are declaring this done.