Password fatigue is something we’ve all experienced at some point. Whether it’s
due to breaches and the ever present, ‘update password’ warnings, the corporate
policy of a 90-day rotation or simply registering for a website with yet another
unique username and password.
Social login or social
sign-in allows people to use their existing
Google,
Twitter, Facebook, LinkedIn or other social credentials to enter a web
property, rather than creating a whole new account for the site. These can be
used to authenticate, verify identity or to allow posting of content to social
networks and the main advantage is convenience and speed.
With
v13,
BIG-IP
APM offers a rich set of
OAuth
capabilities allowing organizations to implement
OAuth
Client, OAuth Resource Server and
OAuth
Authorization Server roles to implement social logins.
Let's look at BIG-IP’s capabilities (from the user's perspective) as an OAuth
Client, OAuth Resource Server. We’ll navigate to our BIG-IP login screen and
immediately you’ll notice it looks slightly different than your typical APM
login.
Here, you now have a choice and can authenticate using any one of the 4
external resources. Azure AD Enterprise and AD B2C along with Google and
Facebook. Google and Facebook are very popular social login choices - as shown
in the initial image above - where organizations are looking to authenticate the
users and allow them to authorize the sharing of information that Google and
Facebook already have, with the application.
In this case, we have an application behind BIG-IP that is relying on getting
such information from an external third party. For this, we’ll select Facebook.
When we click logon, BIG-IP will redirect to the Facebook log into screen.
Now we’ll need to log into Facebook using our own personal information. And with
that, Facebook has authenticated us and has sent BIG-IP critical info like name,
email and other parameters.
BIG-IP has accepted the OAuth token passed to it from Facebook, extracted the
info from the OAuth scope and now the application knows my identity and what
resources I’m authorized to access.
We can do the same with Google. Select the option, click logon and here we’re
redirected to the Google authentication page. Here again, we enter our personal
credentials and arrive at the same work top.
Like Facebook, Google sent an authorization code to BIG-IP, BIG-IP validated
it, extracted the username from the OAuth scope, passed it to the backend
application so the application knows who I am and what I can access.
Let's look at Microsoft. For Microsoft, we can authenticate using a couple
editions of Azure AD – Enterprise and B2C. Let’s see how Enterprise works. Like
the others, we get redirected to Microsoftonline.com to enter our MS Enterprise
credentials.
In this instance, we’re using an account that’s been Federated to Azure AD
from another BIG-IP and we’ll authenticate to that BIG-IP. At this point that
BIG-IP will issue a SAML assertion to Azure AD to authenticate me to Azure AD.
After that, Azure AD will issue an OAuth token to that BIG-IP. BIG-IP will
accept it, extract the user information and pass it to the application.
Finally, let’s see how Azure AD B2C works. B2C is something that companies can
use to store their non-corporate user base. Folks like partners, suppliers,
contractors, etc. B2C allows users to maintain their own accounts and personal
information. In addition, they can login using a typical Microsoft account or a
Google account. In this case, we’ll simply use a Microsoft account and are
directed to the Microsoft authentication page.
We’ll enter our personal info, the servers communicate and we’re dropped into
our WebTop of resources.
Social logins can not only help enterprises offer access to certain
resources, it also improves the overall customer experience with speed and
convenience and allows organizations to capture essential information about
their online customers.
ps
Related:
