Nowadays, many websites require us to create an account on their platform to access their full features. To ensure our online security, it is recommended that we do not reuse passwords. As a result, we are left with multiple passwords to remember, which can be overwhelming. To avoid this, we often log in to websites using external authentication tools such as Google, Facebook or Twitter. OAuth makes this possible, but what exactly is it? In this article, we will explain the concept of OAuth.

What is OAuth?

OAuth is an open standard for authorisation, not an API or a service. It enables any application to implement secure delegated access for client applications to user data without requiring standard credentials. OAuth can be used for server-to-server, web, and mobile applications, and works over HTTPS. It authorises devices, APIs, servers, and applications using access tokens rather than login and password credentials. Its operation can be summarised as providing clients with secure access to server resources on behalf of the resource owner.

It’s important to note that OAuth is specifically for authorisation, not authentication. It allows an authorisation server to issue access tokens to external clients with the consent of the resource owner, such as a Facebook profile. The third-party company can then use the token to access the protected resources hosted by the resource server.

Authentication is the process of verifying that a user or entity is the legitimate owner of the presented identity, which can be done by entering a login and password, a fingerprint or through behavioural biometrics. Authorisation, on the other hand, is the process of granting the appropriate permissions to a user, program, or process to access a particular resource after successful authentication.

Using an existing account to authorize a new website is undoubtedly convenient. It speeds up the registration process and eliminates the need to fill out the form again with our personal information. Additionally, it eliminates the need to remember multiple usernames and passwords, assuming we all use unique usernames and strong passwords for each service. With the OAuth standard, we can use the credentials for the selected service to log in to the application, eliminating the need to remember a large number of login details.

Figure 1. Login screen to the application supporting authorisation via an external service.

The popularity of OAuth is increasing rapidly due to several reasons. Firstly, it is widely supported by many service providers, including Facebook, Twitter, Google, Yahoo, Windows Live, LinkedIn, GitHub, Bitbucket, PayPal, Amazon, Autodesk, Reddit, Evernote, Evernote (sandbox), Exact, and many more. Moreover, the number of service providers supporting OAuth is constantly growing. Additionally, OAuth allows you to create your authorisation server, which gives you unlimited implementation possibilities.

OAuth. Are you interested in the topic? Stay tuned for more on this topic on our blog!

How does it work?

Social media sites act as a form of verification for users. When you opt to log in to an app using Google or Facebook, the login dialogue box that appears is actually provided by the authorisation service and not by the app where you are creating an account. If you are not already logged in to the authorisation service, you will need to provide your username and password, and then you will be asked to grant permission to access a specific range of your data (as shown in Figure 2). The website then confirms to the app that they have verified your identity and that you are who you claim to be, allowing you to proceed.

Figure 2. A prompt asking you to give the client application access to certain ranges of user data.

From a programming point of view, it’s a bit more complex – to properly understand the flow of data when using OAuth, let’s discuss the following roles:

Third-party application: “Client Application/Client”

• A client is an application that tries to access a user’s account (it needs permission from the resource owner).

API: “Resource Server”

• A resource server is an API server used to access a user’s information.

User: “Resource Owner”

• The owner of an asset is the person who gives access to a particular part of their account.

The authorisation process begins when users express their intent to access the API. Here’s how it works (to put it simply):

STEP 1) Authorization

The user selects a social network provider to authorise the client application, which sends a request to the Resource Server for authorisation.

An example request is shown below:

https://authorization-server.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=REDIRECT_URI&
  scope=EXAMPLE_SCOPE&
  state=BfuQzzcMGWbhH

• response_type=code – indicates that the server is waiting for an authorisation code;
• client_id – the client ID you received when you created the app.
• redirect_uri – indicates the URI to which the user is expected to be redirected when authorisation is complete;
• scope — a value containing a list  of scopes that define the permissions to your account that should be granted to the client application;
• state – A random string generated by your app that will be validated later.

If the user is not logged in to the application, calling the oauth/authorize URL  with the parameters described above will redirect to the login page on the website. However, when there is an active user session, the resource owner will be prompted to grant access to specific ranges of user data.

Once the access request is approved, you will be redirected to the client application at the REDIRECT_URI address that was previously specified. The redirect will include two essential parameters: ‘code’, which is the key needed for the client application to generate a token, and ‘state’, which is the parameter that was previously received from the client application.

https://example-app.com/callback?code=AUTH_CODE&state=BfuQzzcMGWbhH

• code  – The server returns an authorisation code in the query string;
• state – The server returns the same status value.

Upon receipt of the request, the state value is validated.

STEP 2) Getting an access token

The client application can exchange the authorisation code for an access token by sending a POST request to the specified endpoint of the authorisation server.

POST https://authorization-server.com/token
  grant_type=authorization_code&
  code=AUTH_CODE&
  redirect_uri=REDIRECT_URI&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

• grant_type=authorization_code – the type of permission for this request;
• code=AUTH_CODE — the code received in response to the previous request.
• redirect_uri=REDIRECT_URI – the value of the URI (analogous to the value provided in the original link)
• client_id=CLIENT_ID – Client ID;
• client_secret=CLIENT_SECRET — client’s secret.

Suppose the verification of our request was successful. In that case, the authorisation server responds by sending us an access token, its expiration time and a refresh token that allows us to generate a new access token without going through the entire login path of the User again.

{ “access_token”:”RsT5OjbzRn430zqMLgV3Ia”, “refresh_token”:”eyJ0eXAiOiJKV1QiLCJhbG”, “expires_in”:3600}

However, if the verification fails, we may receive the following response:

{ “error”:”invalid_request”}

It’s important to note that the user does not need to share their login credentials (such as username and password) with the client application for authorisation purposes. Instead, they securely delegate access through OAuth. At any time, the user can log in to the authorisation service and review the access granted to specific applications. They can also revoke access tokens for those applications if needed.

The presented solution is only a simplified scheme of operation that is not an actual implementation.

Is OAuth secure?

In many ways, logging into third-party services via Google or Facebook is more secure than creating a standalone account and password.

If you do not use a password manager, you possibly use the same login credentials for multiple websites or weak passwords. In case any of these websites get compromised, hackers would be able to deduce your password patterns. This could become even more problematic if you have used the same passwords across different websites, as the hackers would have access to all your accounts. However, with OAuth, you can focus on creating a strong password for the authorisation service you use every day and then use it to access all your accounts.

Weak password – these are short, common words/strings that are easy to guess or crack by performing techniques such as a brute force attack. People often use obvious passwords, like their children’s names or house numbers, so they don’t forget them. However, the simpler the password, the easier it is to detect/crack.

What happens if your authorisation service password is stolen? Wouldn’t hackers have access to everything instead of just one thing?

Regarding services like Gmail, your password is already a potential way for hackers to access everything. If a hacker obtains your email password, they can request a password reset link for any app you used to create an account. The link will be sent to the email address the hacker now controls, so using your Google sign-in credentials for other apps does not increase the risk beyond what the hacker has already gained from accessing your password.

However, big platforms like Facebook, Google, and Twitter have extensive resources and security teams that monitor your account and data, significantly reducing the risk of unauthorised access. These companies understand the importance of securing their customers’ data, as any security vulnerability could result in severe financial and reputational losses.

Two-factor authentication (2FA) is now a standard security measure used by many platforms, including Google and Facebook, to protect users’ data. 2FA provides an additional layer of verification during authentication, making it harder for unauthorised people to access your data. Unfortunately, traditional web applications like online stores or news sites often lack similar security mechanisms, which makes them less secure.

However, not all services prioritise data security. Some platforms still store passwords in plain text or use weak cryptographic algorithms that are easy to crack. That’s why it’s essential to trust the services you use to store your data. Moreover, if you lose access to your account password, having only one account and password to recover is better than dealing with multiple accounts and passwords.

When using third-party sign-in services, it’s crucial to ensure that you trust the application you’re granting permissions to. A rogue website can phish your credentials during the authentication process with the authorisation provider. For example, if you want to use the application XYZ services, ensure that the OAuth transaction to the authorisation service is legitimate. Otherwise, a rogue website could collect your credentials and act as if the OAuth transaction was successful.

Unfortunately, phishing attempts like this are not just theoretical threats. In the second quarter of 2017, one million Google accounts were successfully hacked, and cases like this occur more frequently on Polish websites. Protecting yourself from phishing attempts means ensuring that you enter your credentials only on the original and real domain of the website.

What information does the authorisation service provide to the client application?

It’s crucial to note that authorisation applications do not reveal login or password information to client applications.

For instance, Facebook only shares public profile information such as your name and profile picture, while Google usually provides your email address or phone number to enable contact if necessary.

It’s essential to keep in mind that both services can provide additional information beyond this.

How can you control what information is shared?

It is possible to have control over the data that other applications can access through online services. You can choose which data you want to share with specific limitations. For instance, Facebook has made it easy to manage your data. You can view a list of permissions on the “Privacy” section of your Account Settings page, such as access to your friend list, date of birth, likes, and email address. Also, you can view a list of applications connected to your Facebook account. You can revoke your authorisation to access your account or some of your data at any time.

Figure 3. Manage permissions and client applications connected to your Facebook account.

It is worth noting that Google does not currently offer the same level of flexibility as other app providers regarding the information they collect. App providers usually decide what information they will ask Google for, and in most cases, you can see what’s being shared. Unfortunately, there’s not much you can do about it.

However, each authorization service should contain information about the applications that you have given access to certain areas of your account. To review a list of third-party apps and websites that are connected to your Google Account, go to the “Security” section of your My Account page. On the page, you will find a section called “Apps that have access to your account” that lists apps with access scopes described.

Similar to Facebook, it is important to periodically review and delete any apps that you no longer use. However, unlike Facebook, Google does not provide a breakdown of the shared data and what is kept private.

Figure 4. Manage permissions and client applications connected to your Google Account.

Advantages

Adding social login to the app has advantages for users and website owners.

Easier and faster registration

• From a user’s perspective, signing up using an authorisation service speeds up the authorisation process for a new application. It minimises the number of login credentials that need to be remembered. Consequently, this leads to an increase in user accounts, positively impacting the site’s popularity.

A list of apps you’ve created an account in one place

• Many of us may have encountered a situation where we cannot recall the websites where we used our login credentials to create an account or received an email. Authorisation services are helpful in such cases, as they provide a comprehensive list of all the applications associated with our profile.

Updating your data

• Users don’t usually update their profiles on all the apps they use but usually do it on social networks. Therefore, having a login through a social account makes it so that you only need to change the data in one place, and it will be updated in all related applications.

Verified email addresses

• It is the responsibility of the social network provider to verify the user’s email address. By sharing this information, the app owner can be assured that the email address they receive is accurate. Therefore, if social login is the only way of authorisation, the application does not need a mechanism for verifying email addresses, securing credentials or recovering passwords. This can lead to lower implementation and maintenance costs for the application.

The ease of implementation

• OAuth is relatively easy to implement and allows you to create your authorisation services, which affects the unlimited possibilities of using the standard.

Disadvantages

Limited control

• One major disadvantage of this new trend is that you have limited control over the transferred data. Furthermore, certain websites allow you to log in with Facebook or Twitter to post on your profile. To reduce such risks, carefully review the privacy policy and permissions granted by the app before giving access.

Phishing

• OAuth authorisation, when executed correctly, is secure. However, the authorisation page can be similar to the original page, leading to confusion. To ensure the security of your credentials, always double-check that you’re entering them on the correct URL of the website.
  
  

Lack of implementation interoperability

•  The OAuth standard does not offer a pre-built solution but rather a set of rules and guidelines. As a result, a variety of non-interoperable implementations are created. This requires separate code snippets for each authorisation service, such as Facebook, Google, and others..

Alternatives

Federated identity is the primary goal of similar solutions. It involves using the user’s electronic identity for authorisation in multiple systems. This eliminates the need for the application to obtain credentials to authenticate the user. Instead, the application can rely on an identity management system that stores the user’s electronic identity for authorisation as long as the application trusts the system.

Many people often get confused between OAuth 2.0, OpenID Connect, and Security Assertion Markup Language (SAML), which provides structure to the federation process. In this context, we’ll briefly explain what these standards mean and what sets them apart.

OAuth

As mentioned, OAuth enables secure delegated access, allowing an application to access sources or perform actions on a server as a user without requiring the user to log in or share login credentials. If you have ever agreed to automatically synchronise your Facebook or email contacts when signing up for a new app, you have likely used OAuth 2.0.

OAuth vs OpenID

OpenID and OAuth are used for authentication purposes but have different objectives. OpenID is designed for federated authentication, which allows third-party applications to authenticate users using accounts they already have. On the other hand, OAuth aims to eliminate the need for users to share passwords with third-party applications.

OpenID uses the ID token to provide a unified approach for areas that OAuth 2.0 leaves open to interpretation. It focuses solely on user authentication and is primarily used to allow users to log in to consumer websites and mobile apps. If you have used Google to log in to apps like YouTube or Facebook to log in to your shopping cart, you are already familiar with this authentication option.

The process flow for OpenID is similar to OAuth 2.0, but with the added feature of an ID Token. This token consists of a header, content, and a signature. You can think of it as a concert ticket issued by a resource server. It does not contain any personally identifiable information; it is merely a credential that grants you permission to enter.

OAuth vs SAML

Security Assertion Markup Language (SAML) is a widely used standard for exchanging authentication and authorisation data between identity and service providers. It uses XML to exchange authentication and authorisation messages to verify a user’s identity and permissions, granting or denying access accordingly.

In most cases, you might have encountered SAML authentication in a work environment by logging into your company’s intranet or identity provider. Once authenticated, you are automatically granted access to other services like Salesforce or Workday without entering your credentials again.

Summary:

OAuth is a protocol for authorisation that enables applications to request specific data access permissions from resource owners. Access tokens and refresh tokens are granted upon successful authorisation.

OpenID is a popular authentication method that allows users to log into multiple websites using the same login credentials, such as username and password. Ironically, many internet users use the same login details across various platforms, even when prompted to create new ones. Although this habit helps them remember their login information, it can also put them at risk of cyberattacks since it increases the chances of hackers intercepting their sensitive data.

SAML is a protocol that enables an identity provider to transfer a user’s login information to a service provider. This allows the service provider to authenticate and authorise the user to access a particular service. SAML uses XML to standardise communication between different systems.

Compared to other framework protocols, SAML is relatively older, and it is more commonly used in enterprise applications. However, the developer community has recognised the need for a lighter, more customer-centric framework. This has led to the creation of OAuth, which uses a more lightweight format called JSON to encode data. JSON works better on mobile devices, making it a more suitable option for modern applications.

Keeping your data safe is very important, no matter which solution you use. There are many ways to attack data and just as many ways to protect it. Whether you’re creating an account traditionally or using a third-party login service, ensuring that the site you’re entrusting your information to is trustworthy is essential.

Password hijackings happen more often than you might expect. Remember that you can add an additional layer of security, such as two-factor authentication (2FA), on your Google/Facebook account and other services that offer it. This can be enabled at any time from the management panel.

This introduction should help you understand OAuth better. The next time you see “Log in with Twitter” or a similar delegated identity verification, you’ll be aware of what to look out for.

If you’re interested in this topic, follow our articles! We’ll share more information on creating your own authorisation service with the Laravel framework soon.

---