Have you ever seen such screen? A login page with Facebook, Google, Microsoft buttons but the page does not belong to any of those companies? If so, they most probably use OpenID or OAuth2 protocols to provide you with a possibility to use your social account to log in to that website.
I am going to quickly explain you how it works as simple as I can without simplifying it too much.
I have prepared a video presentation for you.
If you prefer a written version, here it is also.
Traditional authentication
Before we jump to it, let's stop for a moment on traditional authentication concept. Most of the systems we know are built this way.
A user uses an internet browser to access a website. If the website requires authentication, user provides username and password which are verified in the users database. The database is owned by the website owner and is a part of that system. That is simple and works well but from the user perspective there are multiple websites he has accounts in.
Each website has its own accounts database. The user has separate accounts on all those websites. For security reasons it is better for him to use different passwords ... and change all of them regularly. It is a tough work to do for a user.
It would be easier for the user if all those websites had a common users database. He would have only one account for all them.
Obviously, it should be done in a way that none of those websites had access to any other using user credentials, right? I do not want Twitter to read my emails in Gmail but it would be great if I could use the same account to access both applications.
OpenID concept
Fortunately, there is a way to do that. It is called OpenID. It is a protocol without a centralized server. As it is open, there are many Identity Providers like Google, Facebook, Twitter, Microsoft. A user can authenticate to a Relying Party website using an Identity Provider. A user can even choose which one because a webmaster can configure multiple providers on the website. It is crucial that a user password is never sent to a Relying Party as the authentication takes place on an Identity Provider's page.
OpenID is actually a good start but the world has gone a little further and broadly uses OAuth. The concept is very similar so I will focus on OAuth from now on.
So what is OAuth?
It is a protocol based on OpenID but extended a little to allow not only authentication but also authorization. It means that a Relying Party can know who the user is by name, get his email address etc. Of course with a user consent. If the user does not agree, it will not happen.
Let's make sure we understand the difference between OpenID and OAuth. OpenID is used to make sure a user an owner of the identity he claims he is. E.g. an identity can be an account number = 123456 in Google Plus. Relying Party still does not know email address of that account in Google Plus. That is OpenID.
The Relying Party can find out the user email address if it is authorized to query such information from Google Plus. The authorization is handled using OAuth protocol.
As the purpose of OAuth protocol is understood, I will show you how it works in more details. I will focus on OAuth2 as this is the latest and the most popular version of this protocol.
OAuth2 protocol
I am going to present only one positive scenario supported by OAuth2 but there are several more. It should be enough to understand the concept.
The process starts from a user who is trying to enter a website with his internet browser. It results in sending "show me the website" request to the Relying Party. The website needs to know who the user is so it responds with "you have to be authenticated" and the user can choose Identity Provider. He chooses Google which is supported by the website which means that Google Sign In was configured by a web developer. A part of the configuration was assigning an identifier and a secret key to the website. Both are shared between the website and Google. ID is not kept secret. The secret is a key that should never be shared with anyone else than the Identity Provider, Google in this case. If you know the ID and the secret key for that ID, it means that you are that website or its owner. An ID is like a login to your bank account. It is unique but if you share with a theft, he/she still will not be able to still your money. A secret key is like a password to your bank account. If you made it public, anyone could pretend he/she is you and transfer your money out of your account.
Going back to the scenario, the user decided to sign in with Google. The web application responds with a redirect instructions that contain the website ID. A part of the response is encrypted with a secret key. The browser redirects to the Google sign in page providing the website ID and the encrypted part so Google knows the source of the request. When user successfully logs in, Google asks the user to agree on a data scope to share with the Relying Party. This scenario assumes the user agrees so Google generates one time authorization code, encrypts it with the secret key and sends it back with a redirect request to the browser. The browser goes to the Relying Party website forwarding the encrypted authorization code. The Relying Party decrypts it using the secret key and reads the authorization code. Notice that the authorization code is known only by Google and the Relying Party. Even the user is not able to decrypt it as he/she does not know the secret key.
The authorization code allows the Relying Party to ask Google for an access token. In turn, the access token can be used to request user data from Google. Google validates the token and the data scope agreed by the user and provides the Relying Party with requested data. Now, the Relying Party website knows the user identity and can allow him/her to go in.
This is how OAuth2 works in a typical case.
Should I use OAuth2?
If you still hesitate to use OpenID/OAuth2, keep in mind that a user does not have to create a new account in your system. People do not like to create many accounts. We are more keen to use the one we have rather than trying to remember a new password.
If I trust Google that they keep my credentials safe, I do not need the same level of trust to the Relying Party as they never see my password.
As a web application developer, you benefit as well. Creating a custom login system is a well known field but it still requires a lot of coding. Passwords in the database should be hashed, they should have expiration dates. Reset and change password functionality must be implemented. Moreover, you should not allow any password to be set by a user. It should be rejected if it is too simple. It is a lot of work that can be avoided by integrating with an Identity Provider.
In many cases legal side is simpler with OAuth2 because you might not need to gather and process PII data like email addresses, first and last names.
If you are interested in OAuth2 and Google Sign In, you can see how to use Google Sign In with Spring Boot or without Spring Boot with pure Spring Security. You can also see how to read profile details from Google.
