So you have a website or mobile application, and you want to support social login? Consider using the following imaginary website for Acme Incorporated. Instead of your local username and password, you decide to use the “Login with Yahoo” button.
OX enables a domain to define custom authentication scripts. When you click the “Login with Yahoo” button, the login page uses Acme’s OpenID Connect API (served by OX), and includes the GET parameters “auth_mode=yahoo”. This enable OX to select the correct authentication script for Yahoo. This script could use the Yahoo API to validate your current session or to re-direct you for authentication.
Once you are authenticated, you can see a portal with several panels. Each panel is served by a different back-end web server which needs to know your identity in order to display the right content.
Its a bad idea to instruct each backend web application to use the social API directly. If you did that, each application would have to implement business logic for every social login API. If Yahoo or Google updates their API, every application would have to update their code. Plus, introducing new authentication mechanisms would be difficult: you’d have to get every app to do so.
Using the social login API directly could make it hard for the backend web applications to get all the needed information about you. For example, the billing application might need your Acme account number, which Yahoo does not know.
But how does Acme know which person corresponds to which social account? This is where you need to consider enrollment. Frequently, a person with a local account specifies that they want to associate a social account. Or if you first authenticate with a social login, you may need to provide additional information–for example address, phone number, account number–to enable the organization to setup a local account.
In many ways using a social login API is no different from the considerations of using any external authentication provider, for example Duo or OneID. A custom authentication script could even support uber-authentication API’s, like Janrain or Gigya. These services would enable you to create one custom authentication script to support multiple consumer IDP’s.
The key takeaway from this should be the following: within your domain, stick to open standards like OpenID Connect and SAML. This gives you the most flexibility to change your business logic for authentication, without having to update your applications.
The Gluu Server Blog 