Login with external accounting services

[offtherailz]

Purpose

This is an analysis of the various services and protocols available to provide an external login using common accounting protocols (using at least Google or Facebook accounts).

Oauth2 vs OpenID

This is a short description of the features provided by the 2 protocols.

Purposes

OpenID

OpenID was created for federated authentication, that is, letting a third-party authenticate your users for you, by using accounts they already have. The term federated is critical here because the whole point of OpenID is that any provider can be used (with the exception of white-lists). You don't need to pre-choose or negotiate a deal with the providers to allow users to use any other account they have.

OAuth

OAuth was created to remove the need for users to share their passwords with third-party applications. It actually started as a way to solve an OpenID problem: if you support OpenID on your site, you can't use HTTP Basic credentials (username and password) to provide an API because the users don't have a password on your site.

The problem is with this separation of OpenID for authentication and OAuth for authorization is that both protocols can accomplish many of the same things. They each provide a different set of features which are desired by different implementations but essentially, they are pretty interchangeable. At their core, both protocols are an assertion verification method (OpenID is limited to the 'this is who I am' assertion, while OAuth provides an 'access token' that can be exchanged for any supported assertion via an API).

Features

Both protocols provide a way for a site to redirect a user somewhere else and come back with a verifiable assertion. OpenID provides an identity assertion while OAuth is more generic in the form of an access token which can then be used to "ask the OAuth provider questions". However, they each support different features:

OpenID

the most important feature of OpenID is its discovery process. OpenID does not require hard coding each the providers you want to use ahead of time. Using discovery, the user can choose any third-party provider they want to authenticate. This discovery feature has also caused most of OpenID's problems because the way it is implemented is by using HTTP URIs as identifiers which most web users just don't get. Other features OpenID has is its support for ad-hoc client registration using a DH exchange, immediate mode for optimized end-user experience, and a way to verify assertions without making another round-trip to the provider.

OpenID Connect

new version of OpenID (previous was 2.0. OpenID 2.0 is deprecated)

OAuth(2)

The most important feature of OAuth is the access token which provides a long lasting method of making additional requests. Unlike OpenID, OAuth does not end with authentication but provides an access token to gain access to additional resources provided by the same third-party service. However, since OAuth does not support discovery, it requires pre-selecting and hard-coding the providers you decide to use. A user visiting your site cannot use any identifier, only those pre-selected by you. Also, OAuth does not have a concept of identity so using it for login means either adding a custom parameter (as done by Twitter) or making another API call to get the currently "logged in" user.

Technical Implementations

The two protocols share a common architecture in using redirection to obtain user authorization. In OAuth the user authorizes access to their protected resources and in OpenID, to their identity. But that's all they share.

Each protocol has a different way of calculating a signature used to verify the authenticity of the request or response, and each has different registration requirements.

Specific Purposes for Facebook and Google

Both of the protocols provide authentication (OAuth2 has a pseudo-authentication).
Google And Facebook services are a little different in terms of API and provided services.
In particular facebook provides only Oauth2 pseudo-authentication, so most probably we should use OAuth2 at least.

With both you need to register the application (setting also the domains where the authentication come from) to get clientID (google) or appId (facebook) to use in your application to send the authentication requests.

When the user try to login, will be redirected to the specific site with a popup.

When he accepts the required authorization, the application will receive a token. At this point the application can send back the token and the other informations to the backend (note: these information must be sent over https).

Facebook

https://developers.facebook.com/docs/facebook-login/web
At the end of the login process, an access token is generated. This access token is the thing that's passed along with every API call as proof that the call was made by a specific person from a specific app.

The Facebook SDK for JavaScript automatically handles access token storage and tracking of login status in the browser, so nothing is needed for you to store access tokens in the browser itself.

However, a common pattern is to take the access token and pass it back to a server and the server makes calls on behalf of a person. In order to get the token from the browser you can use the response object that's returned via FB.getLoginStatus():

FB.getLoginStatus(function(response) {
  if (response.status === 'connected') {
    console.log(response.authResponse.accessToken);
  }
});
The token is an opaque string of variable length.

Also keep in mind that the access tokens that are generated in browsers generally have a lifetime of only a couple of hours and are automatically refreshed by the JavaScript SDK. If you are making calls from a server, you will need to generate a long lived token, which is covered at length in our access token documentation.

Google

https://developers.google.com/identity/sign-in/web/devconsole-project
Google provides a simple api to sign in. After the sign in, you can send back to your server the token and the other informations needed by the backend.
https://developers.google.com/identity/sign-in/web/backend-auth

Proposed Solution

Current requirements

For the moment the requirement in MapStore 2 is to allow Sign-on/ Sign-in with Google and Facebook (or any other oauth2 service).
This means that at first login MapStore2 should create a new users with the proper and properties. On the next logins, the application will recognize the user by Id and then reuse the same local account information to validate informations if needed. So we don’t need for this purposes, to create any session with Facebook or Google.
In fact, we are not using the informations in an interactive way (e.g. getting likes from facebook, or files from Gdrive), but only on login.

Front-end

Here are some solutions present in the react/redux ecosystem that should speed up the development on client side.

https://github.com/lynndylanhurley/redux-auth

https://github.com/keppelen/react-facebook-login

https://github.com/anthonyjgrove/react-google-login

We should develop the interaction with the backend service to create the account.
In addition, we should provide the possibility to logout from facebook/google contextually with the normal logout (this functionalities are provided by google/facebook SDK).

Session management

At this time, MapStore 2 uses a basic authentication system to login and perform all the requests. If configured, MapStore2 stores user info in the localStorage. Introducing this system means that the user will not have the username/password.
So we have to re-implement the token based session system (See MapStore(1) )
The application should re-use the existing code from OpenSDI 2 to generate and validate tokens. It is already integrated to work with GeoStore and GeoServer.

Backend

We should provide a backend service for sign-on.
This service should provide functionalities to verify the user information and create/update user info in a generic way.
The providers for user validation and informations should be extensible and create an implementation for each provider (we can try to create a generic configurable OAuth2AuthenticationProvider, but if the protocol are too different maybe is a good idea to provide an interface for this, with specific implementations for each provider).

The information about the user (fb-userId) can be stored as GeoStore attributes. There should not be critic informations that can not be stored on user accounts (the token is not needed anymore when the login has been verified, the application should have the access granted to the needed information). Anyway if some of this informations will be needed, we have to support also to have private attributes for the user.

Google:https://developers.google.com/api-client-library/java/google-oauth-java-client/oauth2
Facebook: http://www.adfkickstart.com/facebook-user-authentication-in-java-web-application

Custom Installation

MapStore 2 backend services should find app information in the spring context (external files by propertyOverriders). Each user that wants these functionalities on his own server should register their application on Facebook/Google and properly configure the access parameter.
The customer application should work on https

Draft of tasks

• Front end:
  • Investigate on existing libraries to reuse
  • Properly join to the backend services for sign-on
  • Properly join to the backend services for sign-in (automatic check)
  • Session Management
  • Logout
• Back end:
  • Code Base
  • Session Management
  • Email implementation (optional)
    • Needs email validation
  • Google Implementation
  • Facebook implementation

Future Development

Account union

Future development can allow user to add to their Google/Facebook accounts to their existing ones.

Interaction with Specific services (google, facebook, Github, Amazon…)

Oauth2 can be used to ask additional access request for specific purposes.

Examples:

• Automatic-Upload data on google drive/amazon AWS bukets when a process is finished
• Download data from GDrive/AWS.
• Load data visualization templates from Gist/Github repositories on the fly
• Social networking

Single sign-on services integration

The session service can be used with with single sign-on services (e.g. CAS).

Password recovery

With Email access we should introduce the possibility to recover password using an unique url.

[tdipisa]

closed for inactivity