You may have seen a flurry of articles talking about Google and OAuth and wondered what is going on. What is the big issue? How does it work? And should I be worried? In this blog we will take a look at all of these questions and help you identify if you are at risk.
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:
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:
There is much more to OAuth 2 than just this, but this provides the core concepts relevant to this blog.
The following are the simplified basic steps within OAuth:
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.
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 reregistered that name, then yes.
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).
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.
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
