{ "id": "ab2dbb7e-cb40-49bc-b52e-0ec0b8ce8012", "created_at": "2026-04-06T02:13:15.749748Z", "updated_at": "2026-04-10T03:21:20.842679Z", "deleted_at": null, "sha1_hash": "f59bacb0708da2aa39210fbcf70b3613ac4d06cd", "title": "New Phishing Attacks Exploiting OAuth Authorization Flows (Part 1)", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 66928, "plain_text": "New Phishing Attacks Exploiting OAuth Authorization Flows (Part 1)\r\nBy Jenko Hwong\r\nPublished: 2021-08-10 · Archived: 2026-04-06 02:01:12 UTC\r\nThis blog series expands upon a presentation given at DEF CON 29 on August 7, 2021.\r\nPhishing attacks are starting to evolve from the old-school faking of login pages that harvest passwords to attacks that abuse\r\nwidely-used identity systems such as Microsoft Azure Active Directory or Google Identity, both of which utilize the OAuth\r\nauthorization protocol for granting permissions to third-party applications using your Microsoft or Google identity.\r\nIn the past few years, we have seen illicit grant attacks that use malicious OAuth applications created by attackers to trick a\r\nvictim into granting the attacker wider permissions to the victim’s data or resources:\r\nPhishing Attack Hijacks Office 365 Accounts Using OAuth Apps, Lawrence Abrams, 12/10/2019.\r\nDEMONSTRATION – ILLICIT CONSENT GRANT ATTACK IN AZURE AD / OFFICE 365, Joosua Santasalo,\r\n10/25/2018\r\nInstead of creating fake logins/websites, illicit grant attacks use the actual OAuth authentication/authorization flows in order\r\nto obtain the OAuth session tokens. This has the advantage of bypassing MFA authentication, with permanent or nearly\r\nindefinite access since the OAuth tokens can be continually refreshed in most cases.\r\nIn this blog series, we will review how various quirks in the implementation of different OAuth authorization flows can\r\nmake it easier for attackers to phish victims due to:\r\n1. Attackers not needing to create infrastructure (e.g., no fake domains, websites, or applications), leading to easier and\r\nmore hidden attacks\r\n2. An ability to easily reuse client ids of existing applications, obfuscating attacker actions in audit logs\r\n3. The use of default permissions (scopes), granting broad privileges to the attacker\r\n4. A lack of approval (consent) dialogs shown to the user\r\n5. An ability to obtain new access tokens with broader privileges and access, opening up lateral movement among\r\nservices/APIs\r\nFinally, we will discuss what users can do today to protect themselves from these potential new attacks.\r\nIn Part 1 of this blog series, we will provide an overview of OAuth 2.0 and two of its authorization flows, the authorization\r\ncode grant and the device authorization grant.\r\nOAuth as we know it\r\nThe OAuth 2.0 RFC 6749 was released in October 2012, and OAuth has become the standard for authorizing Internet\r\ninteractions based on your Microsoft Active Directory, Google Identity, or with vendors such as Paypal or Login With\r\nAmazon. \r\nWith OAuth authorization flows, users benefit from:\r\nNot sharing their username and password with 3rd-party websites or applications—authentication is handled by the\r\nidentity provider alone\r\nUsing a centralized set of identity credentials across applications, simplifying password management\r\nThere are multiple authorization flows within the OAuth 2.0 specification that handle a variety of authorization cases. The\r\nflows include web applications/sites, mobile/desktop applications, and devices such as Smart TVs (e.g., authorizing\r\nstreaming video content to your TV). At a high level, all of the OAuth authorization flows involve the following steps in\r\nsome way:\r\n1. An application directs the user to the identity/authorization provider for authentication and authorization of access to\r\nthe user’s data or resources. \r\n2. The user successfully and securely authenticates with the identity/authorization provider\r\n3. Depending upon the flow, the user may be presented with a consent screen that clarifies which permissions are being\r\nrequested\r\n4. After successful authentication and authorization, an OAuth access session token is created that allows API calls\r\nusing the user’s identity with the permissions approved by the user\r\n5. The application obtains the OAuth access token using an authorization code\r\n6. The application then accesses the data or resources required. OAuth access tokens usually expire in one hour, but\r\nrefresh tokens are usually also returned to the application, which can be used to create new access tokens, usually\r\nindefinitely by default.\r\nhttps://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authorization-flows-part-1\r\nPage 1 of 6\n\nMost of us have encountered OAuth as users when authorizing access by applications such as Google Drive, Gmail,\r\nOutlook, or OneDrive. This is the most common flow, called the OAuth authorization code grant. Here we authenticate and\r\nauthorize the Google Cloud CLI, gcloud, to access our GCP environment:\r\n1. Application requests authorization by redirecting the user to the identity/authorization provide\r\n$ gcloud auth login joeblogs@centeneo.com --force\r\nYour browser has been opened to visit:\r\nhttps://accounts.google.com/o/oauth2/auth?\r\nresponse_type=code\u0026client_id=32555940559.apps.googleusercontent.com\u0026redirect_uri=http%3A%2F%2Flocalhost%3A8085%2F\u0026scope=openid+https%3A%2\r\n2. User authentication: Enters username\r\nhttps://accounts.google.com/o/oauth2/auth/identifier\r\n3. User authentication: Enters password\r\nhttps://accounts.google.com/signin/v2/challenge/pwd\r\n4. User authorization: The user is presented with a consent screen and approves the scopes requested by the application\r\nhttps://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authorization-flows-part-1\r\nPage 2 of 6\n\nhttps://accounts.google.com/signin/oauth/consent\r\n5. Confirmation message: In some cases, a successful authorization message is shown.\r\nhttps://cloud.google.com/sdk/auth_success\r\n6. Application continues: The application has retrieved the user’s OAuth access token and can now access resources.\r\n$ gcloud auth login joeblogs@centeneo.com --force\r\nYour browser has been opened to visit:\r\nhttps://accounts.google.com/o/oauth2/auth?\r\nresponse_type=code\u0026client_id=32555940559.apps.googleusercontent.com\u0026redirect_uri=http%3A%2F%2Flocalhost%3A8085%2F\u0026scope=openid+https%3A%2\r\nYou are now logged in as [joeblogs@centeneo.com].\r\n$ gcloud projects list\r\nHere is what’s happening under the hood of the above flow:\r\nhttps://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authorization-flows-part-1\r\nPage 3 of 6\n\nDevice Authorization Grant\r\nA new authorization flow, called device authorization grant, described in RFC 8628, was added in August 2019. Its purpose\r\nwas to allow easier OAuth authorization on limited-input devices, such as smart TVs, where inputting credentials is tedious\r\nusing TV remote controls, for enabling services such as video streaming subscriptions:\r\nhttps://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authorization-flows-part-1\r\nPage 4 of 6\n\nWith device code authorization implemented, instead of the above, the user might see an authentication/authorization\r\nprocess that looks more like this:\r\nNow, the user can use a richer-input device such as a smartphone or computer to enter a short code in a login screen with a\r\nshort URL in order to authenticate and authorize the smart TV to access content such as the user’s streaming video\r\nsubscription.\r\nhttps://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authorization-flows-part-1\r\nPage 5 of 6\n\nUnderneath the above user experience is the device code flow:\r\nConclusion\r\nThere are at least three more flows in OAuth 2.0, and it’s fair to say that OAuth is complicated. \r\nIt’s trying to bring secure authorization to complex interactions among three parties (identity/authorization provider,\r\nuser, application/client/device), making it a challenge to secure against attackers who are looking to insert themselves\r\ninto this process\r\nIt’s difficult to understand, by users and security professionals alike, making it difficult to secure (e.g. “What’s this\r\nlong code I’m looking at?”)\r\nIt has to cover a variety of use cases including web server apps, native/mobile/desktop apps, devices, and javascript\r\napps, with different flows for each, and with each flow having its own peculiarities and opportunities for abuse\r\nAt the same time, the OAuth protocol was not designed to address other important issues like the identity of each of the\r\nthree parties. A user does authenticate with the identity system, but the application’s identity and, more importantly, the\r\ntrustworthiness of the application is not addressed by OAuth. This, along with the complexity, leads to several areas that can\r\nbe abused by attackers.\r\nIn Part 2, we will dig further into how a phishing attack is carried out using the device authorization grant flow.\r\nSource: https://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authorization-flows-part-1\r\nhttps://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authorization-flows-part-1\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authorization-flows-part-1" ], "report_names": [ "new-phishing-attacks-exploiting-oauth-authorization-flows-part-1" ], "threat_actors": [], "ts_created_at": 1775441595, "ts_updated_at": 1775791280, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/f59bacb0708da2aa39210fbcf70b3613ac4d06cd.pdf", "text": "https://archive.orkl.eu/f59bacb0708da2aa39210fbcf70b3613ac4d06cd.txt", "img": "https://archive.orkl.eu/f59bacb0708da2aa39210fbcf70b3613ac4d06cd.jpg" } }