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.

This was last published in December 2019

Dig Deeper on Enterprise identity and access management

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

I believe ‘bring your own identity’ is on the horizon, I tend to prefer consumer ID - which clashes with customer IAM or CIAM. Here's the thing, commercial retailers, utility companies or any ecommerce site will not need to manage or persist a customer repository if using BYO-ID! Business will get to reduce cost and liability if outsourcing identity to consumer ID, apart from the obvious, the liability is reduced as the OIDC consent model implicitly provided puts the control and 'scope' of data a business is allowed to use in the hands of the consumer.

Vendors like Okta may well have the bandwidth to host BYO-ID, but I would see a mobile network operator (MNO) hosting this type of service maybe in partnership with a big credit card partner. BYO-ID could be a real boost for ARPU figures and the credit card partner could even contribute if the phone owner holds the right card.

Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

Close