What is OAuth?
Let’s start off looking at what OAuth actually is – you'd be forgiven for assuming the ‘Auth’ part relates authentication but that's not really the case. "OAuth" actually stands for “Open Authorization”. This is an important distinction as the protocol is about authorization not authentication.
What is the difference, you may well ask? Well essentially:
Authentication is about proving who you are; that is, it is sued to verify a user’s identity. This might be done via a username and a password, pin or other information.
Authorization on the hand relates to what you are allowed to do or use; that is what permissions you have or do not have to access different resources.
For example, if you have a website where users might have to log in to use the site; this would call on the verification part of the security system. However, once logged in, some users may only have access to certain aspects of the web site while other users may have access to a wider set of features or functions – this relates to what they are authorized to use. As a concrete example, a standard Microsoft 365 user may not have access to controls and dashboards that an administrator would have.
Back to OAuth! Strictly speaking, there are two versions of OAuth - version 2.0 replaced 1.0 way back in 2012 and is now the de facto industry standard for online authorization; from this point on when we mention OAuth we are referring to OAuth 2.0.
The aim of OAuth is to allow a user using one web site or application, to access resources hosted by another web site or application, based on their authorization. To do this OAuth uses Access Tokens; an Access Token is a bit of data that represents an authorization on behalf of a user to access a resource. Here resource could be anything including a web page, a web site, functionality on a web page, a web application, a mobile application, an image, some data within an application or web page, Smart TV, desktop application etc.
This idea of resource is one of the key components within the OAuth specification. There are several such components including:
Resource Owner: The owner of the resource being protected; such an owner can grant access to the resource.
Client: The system that is requesting access to the protected resource. To access the resource the Client will need to obtain an Access Token.
Authorization Server: The server that receives requests from the Client for an Access Token. To obtain an Access Token the Client will need to Authenticate.
Resource Server: The server that provides access to the resource on receipt of a valid Access Token.
There is much more to OAuth 2 than just this, but this provides the core concepts relevant to this blog.
How Does OAuth Work?
The following are the simplified basic steps within OAuth:
An application / web site requests access to some restricted resource.
A check is made by the owner of the restricted resource to an Authorization server to check to see if they are known and whether they can access the resource. To do this it supplies the client information and an endpoint URI to send the Access Token to.
The Authorization server verifies (authenticates) the client to check that they are who they say they are.
The Authorization Server sends the Access Token back to the application confirming or denying the Client.
Now in possession of the Access Token the application / web site allows the client access to the restricted resource from the Resource Server.
So what is the big issue?
The recent problem with Google’s “Sign in with Google" system is related to domain names. For example, if my application checks with Google that Tom from Framework Training is in fact Tom from Framework Training then Google will reply back with some information confirming their domain and their email address.
This is all well and good for Framework Training as they are a well-established organisation and absolutely still in business!
However, what happens if we are talking about some small start-up company called ‘zzzoft’ (please note, as far as we could see there is no such company – we are just using this made up name as an example). The company employees a few employees and uses Googles OAuth system to allow them to gain access to various systems such as HR systems, client accounts, DM system such as Slack, Zoom etc. However, it turns out that no one is interested in zzzsot’s whizzy new app and after a year and a bit the company goes bankrupt and folds. However, its shiny new domain zzzsoft.com is still around. It can now be bought by someone else; indeed, there are very, very many failed startup domains available for purchase from many different organisations.
So, what you may ask? Well, if I now buy zzzsoft.com I can use it to fool Google into thinking that I am zzzsoft and when another application tries to very a user with google using OAuth I will be asked to verify a zzzsoft user. Which once done gives me access to that user’s login on some system, such as Slack or Zoom or a HR system etc.
This is because the authorization and authentication process is based on the domain and their email. Of course, the requesting application could require additional security checks, but here’s the thing, many don't many just rely on the presence of the access token confirming the domain and the email. For example, they might say that anything from zzzsoft.com domain can log into this system and the email joe@zzzsoft.com is used to allow access to Joe’s data within the system.
Does it have anything to do with me?
This is a trickier question to answer than it may seem! If you have ever worked for a failed start-up company, then possibly yes. If you have worked for a company that has changed its name and potentially its domain and then not re-registered that name, then yes.
What can be done?
In essence this is a fix that only Google can resolve; there is little that downstream applications can do if Google provides an appropriate Access Token to them. Some fixes have been proposed and as of the end of 2024 Google has been officially looking into this issue (although it was originally reported to Google back at the end of September 2024 and initially Google rejected it as an issue).
Summary
In summary, this seems like a fundamental issue for Google and hopefully they will now react quickly to this problem. Whether you are directly affected by it will depend on whether you have been involved with an organisation that no longer registers their domain themselves and have previously used it as part of an OAuth system. If you are an organisation relying on Googles OAuth systems; then care may well be the watch word.
Would you like to know more?
If you want your staff to have greater understanding of IT security, we have a great range of courses ranging from Cyber Awareness for non-technical staff, through to Web Application Security with OWASP, and DevSecOps