Adding a social user authentication to a web application

By Yulia Tarima

Your web app might want to let users register using their social (Google, Facebook and the likes) account.

The communication schema would look something like this:

  1. User opens registration page
  2. Clicks “Register with Google” button
  3. He is redirected to Google’s OAuth2 page where he can accept request
  4. After making sure make sure the e-mail address is an existing one,
    result containing id_token (JWT signed by google) is returned to the front-end application.
  5. After successful token validation it is up to the web application what to do next. For example it could save user’s e-mail address.
  6. The web application can fill some registration fields (for example e-mail address) using the result and can choose to send a registration request to back-end.

Authentication vs Authorization

  1. authentication

    is telling “who you are”.

  2. authorization

    is about “what you can do”,
    e.g. getting access to some resources if you have a token.

OpenID vs OAuth

The problem with 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.

The two protocols share a common architecture
in using redirection to obtain user authorization.
Both protocols provide a way for a site
to redirect a user somewhere else
and come back with a verifiable assertion.

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.

  1. OpenID
    is an open standard and decentralized authentication protocol controlled by the OpenID Foundation.

    OpenID takes the form of a unique URI managed by some “OpenID provider” i.e identity provider (idP).

  2. OAuth
    is an open standard for access delegation.

    OAuth can be used in conjunction with XACML where OAuth is used for ownership consent and access delegation whereas XACML is used to define the authorization policies.

  3. OpenID Connect (OIDC)
    combines the features of OpenID and OAuth,
    i.e. does both Authentication and Authorization.

    OIDC uses simple JSON Web Tokens (JWT), which you can obtain using flows conforming to the OAuth 2.0 specifications. OAuth is directly related to OIDC since OIDC is an authentication layer built on top of OAuth 2.0.


An organisation uses ID card for identification purposes
(ID card acts as a OIDC)

Id card contains chips,
it stores details about Employee
along with Authorization i.e. Campus/Gate/ODC access.
(Chip act as a OAuth)

OpenID OAuth
  • User wants to access his account on example.com
  • example.com (the “Relying Party” in OpenID lingo) asks the user for his OpenID
  • User enters his OpenID
  • example.com redirects the user to his OpenID provider
  • User authenticates himself to the OpenID provider
  • OpenID provider redirects the user back to example.com
  • example.com allows the user to access his account
  • User is on example.com and wants to import his contacts from mycontacts.com
  • example.com (the “Consumer” in OAuth lingo) redirects the user to mycontacts.com (the “Service Provider”)
  • User authenticates himself to mycontacts.com (which can happen by using OpenID)
  • mycontacts.com asks the user whether he wants to authorize example.com to access his contacts
  • User makes his choice
  • mycontacts.com redirects the user back to example.com
  • example.com retrieves the contacts from mycontacts.com
  • example.com informs the user that the import was successful

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 was created for passwordless authentication,
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.

Technical Implementation
of assertion verification method

OpenID authenticates single sign-on identity.

It provides an identity assertion:
the user authorizes access to their identity.

OpenID is limited to the ‘this is who I am’ assertion

In OAuth the user authorizes access to their protected resources.

OAuth provides an ‘access token’ that can be exchanged for any supported assertion via an API
(token can then be used to “ask the OAuth provider questions”)

authentication vs. authorization

OpenID is (mainly) for identification/authentication,
so that web app knows that a user owns user.name@gmail.com account
and therefore user should be same person who owned user.name@gmail.com yesterday
and earned some reputation points.

OAuth does not end with authentication
but provides an access token to gain access to additional resources.

It is designed as delegated authorization,
meaning you are authorizing a third-party service
access to use personal data,
without giving out a password.

Flickr uses OAuth to allow third-party services to post and edit a persons picture on their behalf, without them having to give out their flicker username and password.

User can restrict what information is flowing from identity provider (e.g., Facebook)
to service provider(web app)
Web app should ask permission to take actions on your behalf,
to, e.g., Tweet on your behalf automatically, without knowing your Twitter password.

Open ID gives you one login for multiple sites.

Each time you need to log into a web app using Open ID,
you will be redirected to your Open ID site where you login,
and then back to the app.

OAuth lets you authorise one website (the consumer),
to access your data from another website (the provider).

With OAuth, you still need to log into the provider. e.g. When a consumer app sends you to Flickr, you still have to log into Flickr (or be logged in already). How Flickr decides you’re logged in is completely orthogonal to OAuth. It could be a standard username-password login, it could be via a physical password device, or it could well be via Open ID.

Sharing user data

With Open ID, there is no suggestion of two web apps sharing your data.

Except in the very limited sense
that the Open ID provider may hold some general information about you,
e.g. some photos, addresses, phone numbers, etc.,
and with your consent, send it back to the consumer
so you don’t have to re-enter all the boring profile details again.

However, this is data of a generic, non-application-specific, nature.
And even this limited form of sharing is an extension to the core Open ID spec.

Sharing data is not a problem Open ID solves.
Even if Facebook and GMail used Open ID
and you had accounts with both against the same Open ID,
you still couldn’t get Facebook to read your GMail account.
The Open ID provider wouldn’t let Facebook log in to GMail as if it was you.

With OAuth, any information you hold on any website
can be shared with another website.

E.g., you could copy your GMail address book into Facebook, by allowing Facebook to read your GMail account without sharing your username and password. OAuth prevents it by explicitly asking you if you want to let Facebook grab your details from the provider.


The most important feature of OpenID is its discovery process.

OpenID does not require hard coding each of 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.

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.

Also OAuth “sessions” generally live longer than user sessions.

Two main OAuth2 flows

  1. code
  2. implicit

    returns token directly to the caller

Authentication/Authorization Services/Solutions


  1. Sign-In
    Read more >>>
  2. One Tap sign-in and sign-up
    Read more >>>
  3. Firebase Authentication

    FirebaseUI provides a drop-in auth solution that handles the UI flows for signing in users with email addresses and passwords, phone numbers, and with popular federated identity providers, including Google Sign-In and Facebook Login.

    To sign a user into your app, you first get authentication credentials from the user. These credentials can be the user’s email address and password, or an OAuth token from a federated identity provider. Then, you pass these credentials to the Firebase Authentication SDK. Our backend services will then verify those credentials and return a response to the client.

    After a successful sign in, you can access the user’s basic profile information, and you can control the user’s access to data stored in other Firebase products. You can also use the provided authentication token to verify the identity of users in your own backend services.

    Anonymous auth: Use features that require authentication without requiring users to sign in first by creating temporary anonymous accounts. If the user later chooses to sign up, you can upgrade the anonymous account to a regular account, so the user can continue where they left off.

    Pricing: open source

    Read more >>>


Pricing: up to 2 providers and 7,000 active users free, otherwise can get expensive

Good resources to read:


Leave a Reply or Comment

Your email address will not be published. Required fields are marked *