Social login in 5 minutes chrono

You need to enable the end users of your web site to identify themselves but you have no desire or capacity to handle and authentication server and its passwords related risks — not to mention that your users won’t want to create yet another internet login / password.

This article is presenting a newborn solution worth looking at. I tested it and thought it was worth a small article.

Trusstee default app after a few minutes

1. Let’s get started: identify yourself as application developer:

Browse to https://trusstee.io web site that presents their services. At a glance, they address simplification of authentication for teams starting their business by proposing an online authentication service across multiple social providers.

In the top-right corner of their welcome page click the Sign-in button and they present a list of available identity providers you can choose from to authenticate.

Once you have authenticated with your preferred provider, you reach a dashboard with 3 blocks: Domain, SSO and API.

Let’s focus on the “SSO” type that represents the capacity for your application to authenticate users via their existing social login. Exactly what we need right !

2. Declare your application

Entering the SSO panel, you see a page where you can click on “New app” and enter a form to declare your application.

Fill the form as per the screen shot below:

• the name of your app: My App (of course this is an example 😉)
• select “Authentication service”
• click on the social providers you want your users to be able to connect from. They move to the right when selected.

Now a few elements that are OpenId Connect concepts (if you are not familiar with them, the solution does not expect you to have that knowledge):

• check “via backend” if your application has a server side (e.g. not SPA) and you wish to get the user info on the back-end.
• check “via frontend” if your application is a SPA or you are fine in getting the user info in the front end javascript. It is using the so called PKCE (pronounced pixie) code flow to secure the authentication. This is what we will test here.
• enter the url of your application : it is the page that must be authorised to receiving the temporary secret to get the user information (the code in the code flow of the OpenID / OAuth2 process). It is possible to enter wildcards but keep in mind that it is a security feature and not just a redirection url.
  Set it to “http://localhost:8088/callback.html” to follow this tutorial.

Then “Create the application”. You get a summary page of the application with the OAuth2 info (client_id, client_secret) are presented. Don’t bother writing it down, it will be available in the template download below.

Summary of the created app

3. Download the example and run it

Now we are ready: our new app exists in Trusstee and can be used to authenticate. Go back to the Dashboard page, it now has “1” in the SSO category. click on it and click again on “My App”. You see the edition page of the application where you can change the configuration:

• name of the app
• selected social providers
• edit the allowed redirect urls. The “https://trusstee.io/+” seems to be added when the integrated testing tool is enabled. You can remove it safely.

These features can be changed at anytime after you application is in place to change its settings.

Click the “Pure HTML” template to start with a front-end authentication. It downloads a zip file with all you need to start.

• `readme.txt` gives some explanation and recall the client id and secret
• `index.html` will present the login buttons
• `callback.html` will receive the secret code and display the user information

Expand and run the content of the zip in a web server (I use php cli):

$ Downloads > php -S localhost:8088 -t html
PHP 7.3.24-(to be removed in future macOS) Development Server started at Mon Jan 18 20:02:50 2021
Listening on http://localhost:8088
Document root is /Users/guenole/Downloads/html
Press Ctrl-C to quit.

Navigate to the site url (it loads the index.html page).

index.html

Click on a displayed social provider, follow the authentication process of that provider; accept to grant Trusstee access to your email and basic profile. The “consent” screen is part of the OAuth2 standard and are specific to each provider. Once successfully authenticated the callback.html page displays a json object with a mix between the user info and technical info that correspond to an OpenID id_token.

callback.html: Result of the authentication

“Et voilà!”, you have your own app has authenticated a user via any social login. You can now process, store, use and reuse user info — but always with care and respect for their privacy.

In their T&Cs, Trusstee assure that they do not keep any record of your user’s info:

As a matter of principle in our “trust in service” WE DO NOT, AND WILL NEVER, RECORD, STORE, SHARE, SELL ANY OF THEIR INFORMATION.

4. Looking into the code

The template provided by Trusstee is well documented so I will focus on the 3 main elements:

• HTML to load the social login buttons in index.html:

• Javascript in the index.html to configure the buttons that when clicked will start the OpenID Connect code flow process. This is where the url of your callback page and any info (state) you need to keep are specified:

• Javascript in the callback.html page that will finish up the OpenID Connect process and convert the received code into user info.
  Regardless of the social provider selected by the user, the user info always has the same structure. Trusstee performs a basic standardisation close to the specification. But not all fields are available.

The uniqueUserId (the sub claim) is made of the url of the social provider (what is also called the issuer) and the unique id of the user in that provider. This makes a unique identifier of the user connecting to your site.

This last snippet of code is where you add your custom logic to check the existence of the user in your database, register it, collect its rights, create a session etc.

5. Going further

You may have noticed that the index page proposes a “Popup Login” and “Silent Login”. It seems to be a convenient way to perform the authentication in a popup when redirection is not desired or, respectively, in an hidden iframe.

Additionally, the second template, “Simple NodeJS” is very similar in nature but it demonstrates the back-end authentication flow using the certified external openid-client library.

If you are interested I will dig further and make another article.

Please leave comments and suggestions on what can be interesting with this product.