What is this?

This component provides you with an easy drag and drop mechanism to authenticate an user against multiple OAuth providers like Facebook, GitHub, Google...

Benefits

All in one robust OAuth authentication with error handling. Easy to use, web block drag and drop fashion.

Basic/no OAuth knowledge required (you will still need to create and configure the APP at the provider). Abstraction to OAuth implementation details like CSRF check, authentication, REST mechanisms and scopes.

What are the supported providers?

For now, Facebook, GitHub, Google, Instagram and Linkedin.

What user info is retrieved from providers?

Only basic information is retrieved, i.e., user ID, name and email, depending on the Scope you specify.

The Scope is a static entity, there is no need for you to worry about endless and unstandardized provider scope lists.

Security

CSRF checks are implemented. As for sensitive data, only access tokens are stored in Session, for a one time usage. Other sensitive data like app secrets and client id's are passed as input configuration parameters.

Authorization header is used in all REST calls.

Feedback

Please feel free to drop your feedback and suggestions to make this a better component.

OAuth Overview (adapted from https://tutorials.jenkov.com/oauth2/overview.html)

First the user accesses the client web application (in this case SocialLoginDemo). In this web app there is a button saying "Login via Facebook" (or some other system like Google or Twitter).

Second, when the user clicks the login button, the user is redirected to the authenticating application (e.g. Facebook). The user then logs into the authenticating application, and is asked if she wants to grant access to her data in the authenticating application, to the client application. The user accepts or denies.

Third, the authenticating application redirects the user to a redirect URI, which the client app has provided to the authenticating app. Providing this redirect URI is normally done by registering the client application with the authenticating application. During this registration the owner of the client application registers the redirect URI. It is also during this registration that the authenticating application gives the client application a client id and a client password. To the URI is appended an authentication code. This code represents the authentication.

Fourth, the user accesses the page located at the redirect URI in the client application. In the background the client application contacts the authenticating application and sends client id, client password and the authentication code received in the redirect request parameters. The authenticating application sends back an access token.

Once the client application has obtained an access token, this access token can be sent to the Facebook, Google, Twitter etc. to access resources in these systems, related to the user who logged in.