Login.gov starts to fill the gap between social logins and enterprise identities
Access federal services with a service designed for governmental use but that uses common standards.
There’s been talk and hope for years around eventually seeing the introduction of a social identity provider built for work applications, but so far nothing has surfaced. Despite that, we have seen more social login products enter the marketplace from vendors like Google, Facebook, and most recently Apple.
If you’re not familiar with all of these identity terms, a social IdP, or more commonly known as a social login, is the process that lets you use your existing account from a social media site to log into additional applications. (So, you probably do this with tons of random apps and websites already.) This reduces the need for someone to make an account for every app and worry about them storing your password.
So, taking this concept farther, in addition to consumer-facing social IdPs, did you know there’s also one for U.S. federal agencies called login.gov? We thought this was interesting, since it is a step towards using social IdPs and third-party IdPs for more high-stakes purposes.
Login.gov background
Login.gov provides users, both government employees and citizens, federated single sign-on access to U.S. federal agency accounts. The experience is kind of like what you’d be familiar with when using a typical social login—you just have one set of credentials you use when you sign up for new services—but, of course, the authentication and identity proofing requirements can be stricter, since we’re talking about important personal information, not a random app that lets you download GIFs.
Login.gov went live two years ago, after officially being announced in 2016 under the General Services Administration. The current iteration of a social login for federal access was borne out of the ashes of Connect.gov, which was the first attempt at offering one account for all government services. It was developed by the National Strategy for Trusted Identities in Cyberspace in 2011, with it going live three years later. Login.gov would officially replace it in 2017.
The federal technology organization 18F helped design login.gov. The open-source social IdP supports the common federation standards SAML and OpenID Connect, and all of its code is available on Github.
The official notice [PDF] laid out the goals of login.gov, including having it be citizen centric, use personal information for identity proofing, and users must be authenticated at login for the level of access specified by each agency.
The notice only specifies two levels of access (LOA): LOA1 and LOA3, with corresponding info needed. For LOA1, you provide an email, password, and phone number, while LOA3 requires additional personal information for identity proofing.
This often involves users providing their full name, date of birth, address, phone number, Social Security number, and answering credit and financial questions. This personal data will be kept within the system, presumably to help validate future login attempts. However, users do have control over their data and can request where it’s shared and whether to delete it. The personally identifiable information will be assigned a unique identifier number to associate with the user.
The identity proofing puts login.gov above social logins like Google and Facebook in what they require to be sure the user is who they claim to be. And, it should require a lot given the government has access to much more than your average app!
Another feature that puts login.gov over other social IdPs is the fact that not only is there two-factor authentication, but it’s mandatory. Users can opt to use SMS, phone call, authentication app, security key, or backup codes. Federal employees can also use CAC or PIV. I like that 2FA is mandatory and cannot be turned off. While I’m not a fan of SMS being an option, the summary of a webinar from earlier this year from the FIDO Alliance does make it sound like they don’t like how many people use SMS, too.
Login.gov is only designed to handle authentication, with agencies needing to handle session management and authorization individually. Some example use cases include USAJOBS, for signing up for Global Entry with the U.S. Customs and Border Protection, and the Social Security Administration.
Final thoughts
We may not be about to do away with passwords anytime soon, but having fewer accounts to manage would make everyone’s lives much easier.
Jack told me about how back in the consumerization days, people were talking about a social login for work. It would be taking BYO to the extreme with ‘bring your own identity.’
Another way of looking at social logins is like this: We use Facebook and Google to federate with consumer-oriented applications, and you have your work identity for federating with enterprise SaaS apps. But, in the middle where we have banking, healthcare, and government apps, we’re stuck making unique accounts for each one. This is where federation would also be useful and where login.gov is a step in the right direction.
We haven’t seen much evidence of this happening on the enterprise side. Letting a user, even if they’re just a contractor, login with a consumer Facebook account to do work sounds pretty out there. But clearly there continues to be interest in social IdPs in general. At Oktane 2019, during their closing keynote, Okta maybe danced around the concept, discussing how since Okta has become so big they can begin to leverage that and offer a “Sign in with Okta”-like product. We’ll be watching this.
But again, for now, it’s great to see login.gov begin to bring the identity federation / social login concept to new areas of identity.
