{"id":1845,"date":"2025-07-12T10:46:28","date_gmt":"2025-07-12T10:46:28","guid":{"rendered":"https:\/\/shreyapohekar.com\/blogs\/?p=1845"},"modified":"2025-07-12T11:15:20","modified_gmt":"2025-07-12T11:15:20","slug":"what-is-oauth-real-world-examples-and-various-oauth-attacks","status":"publish","type":"post","link":"https:\/\/shreyapohekar.com\/blogs\/what-is-oauth-real-world-examples-and-various-oauth-attacks\/","title":{"rendered":"What is OAuth, real-world examples and various OAuth attacks"},"content":{"rendered":"\n

OAuth is everywhere\u2014from signing into your favorite apps using Google or GitHub to enabling secure access between APIs. But while OAuth is incredibly powerful, it\u2019s also one of the most misunderstood and misconfigured components in modern applications. And that\u2019s exactly why knowing its fundamentals isn’t optional\u2014it’s critical<\/strong>.<\/p>\n\n\n\n

Misconfigurations in OAuth can open doors to serious vulnerabilities such as account takeover, token leakage, authentication bypass<\/strong>, and privilege escalation<\/strong>. These aren\u2019t just theoretical risks\u2014they\u2019re some of the most commonly exploited bugs in real-world bug bounty reports and security audits<\/strong>, often leading to severe business impact.<\/p>\n\n\n\n

In this blog series, we\u2019ll break down OAuth in a simple, understandable way\u2014covering how it works, the common pitfalls, types of attacks to watch out for, and how to defend against them effectively.<\/p>\n\n\n\n

OAuth: Overview<\/strong><\/h3>\n\n\n\n

OAuth (Open Authorization) is an open standard protocol that allows secure, delegated access to a user’s resources without exposing their credentials. It is commonly used to enable third-party applications to access a user\u2019s data on services like Google, Facebook, and GitHub.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Sure! Here’s a human-friendly, real-world example to make the concept of OAuth easier to understand:<\/p>\n\n\n\n

\n\n\n\n

Real-World Example of OAuth<\/h3>\n\n\n\n

Let\u2019s say you\u2019ve just downloaded a new photo editing app on your phone. The app asks, \u201cDo you want to import photos from your Google Drive?\u201d<\/em> You click \u201cYes\u201d<\/strong>, and suddenly you’re taken to a Google login screen\u2014not inside the app, but on Google\u2019s official website. You log in, give permission to access only your photos (not your emails or calendar), and you’re redirected back to the app, which now has access to your pictures.<\/p>\n\n\n\n

Here’s what just happened behind the scenes:<\/p>\n\n\n\n

    \n
  • The photo app never saw your Google password<\/strong>.<\/li>\n\n\n\n
  • You only gave limited access<\/strong> (photos, not emails).<\/li>\n\n\n\n
  • You could go to your Google account later and revoke that access anytime<\/strong>.<\/li>\n<\/ul>\n\n\n\n

    This is OAuth in action.<\/p>\n\n\n\n

    It allows the app to access your data securely and with your consent<\/strong>, without ever needing to store or manage your actual credentials.<\/p>\n\n\n\n

    \n\n\n\n

    Key Components of OAuth<\/strong><\/h3>\n\n\n\n
      \n
    1. Resource Owner:<\/strong> The user who authorizes access to their data.<\/li>\n\n\n\n
    2. Client:<\/strong> The third-party application requesting access to the user’s resources.<\/li>\n\n\n\n
    3. Resource Server:<\/strong> The API that holds the protected resources (e.g., Google Calendar).<\/li>\n\n\n\n
    4. Authorization Server:<\/strong> Issues access tokens after authenticating the user.<\/li>\n<\/ol>\n\n\n\n
      \n\n\n\n

      OAuth Grant Types<\/strong><\/h3>\n\n\n\n

      OAuth supports different types of grants depending on the use case:<\/p>\n\n\n\n

      1. Authorization Code Grant<\/strong><\/h4>\n\n\n\n

      This is a widely used grant type and you use it on a day to day basis.<\/p>\n\n\n\n

        \n
      • Flow:<\/strong>
        a. The client directs the user to the authorization server.
        b. The user authenticates and grants permission.
        c. An authorization code is sent to the client.
        d. The client exchanges the code for an access token.<\/li>\n\n\n\n
      • Use Case:<\/strong> Web and mobile applications<\/li>\n<\/ul>\n\n\n\n

        <\/p>\n\n\n\n

        You must use this grant where you have the following requirements.<\/p>\n\n\n\n

          \n
        • Your app is a server-side web application<\/strong>.<\/li>\n\n\n\n
        • You can safely store<\/strong> secrets (like client_secret<\/code>) on the server.<\/li>\n\n\n\n
        • You need secure, long-term<\/strong> access to a user\u2019s data.<\/li>\n\n\n\n
        • You want to avoid exposing tokens to the browser or front-end.<\/li>\n<\/ul>\n\n\n\n
          \"\"<\/figure>\n\n\n\n

          2. Implicit Grant (Deprecated)<\/strong><\/h4>\n\n\n\n
            \n
          • Flow:<\/strong> The access token is returned directly in the redirect URL.<\/li>\n\n\n\n
          • Use Case:<\/strong> Browser-based apps.<\/li>\n\n\n\n
          • Security Concern:<\/strong> Prone to token leakage and is largely discouraged.<\/li>\n<\/ul>\n\n\n\n

            3. Resource Owner Password Credentials Grant<\/strong><\/h4>\n\n\n\n

            The Resource Owner Password Credentials Grant<\/strong> is an OAuth 2.0 flow where the user directly shares their username and password<\/strong> with the application. The app then sends these credentials to the authorization server in exchange for an access token.<\/p>\n\n\n\n

              \n
            • Use Case:<\/strong> Trusted applications like first-party mobile apps.<\/li>\n<\/ul>\n\n\n\n

              Imagine a command-line tool built by a company that also owns the OAuth provider. The tool needs access to a user’s Google Drive files.<\/p>\n\n\n\n

              With ROPC<\/strong>:<\/p>\n\n\n\n

                \n
              1. The user provides their Google email and password directly<\/strong> into the CLI tool.<\/li>\n\n\n\n
              2. The tool sends these credentials (along with its own client ID and secret) to Google\u2019s authorization server.<\/li>\n\n\n\n
              3. If the credentials are valid, Google returns an access token<\/strong> to the tool.<\/li>\n\n\n\n
              4. The CLI tool then uses that token to access the user’s Google Drive files.<\/li>\n<\/ol>\n\n\n\n
                  \n
                • Security Concern:<\/strong> Requires sharing sensitive user credentials, making it less secure.<\/li>\n<\/ul>\n\n\n\n

                  4. Client Credentials Grant<\/strong><\/h4>\n\n\n\n
                    \n
                  • Flow:<\/strong> The client (e.g., a backend service or microservice) directly authenticates itself to the authorization server<\/strong> using its own credentials (client ID and secret) and receives an access token.<\/li>\n\n\n\n
                  • Use Case:<\/strong> Used for server-to-server communication<\/strong>, where no end user is involved<\/strong>. For example, a microservice fetching data from another internal service.<\/li>\n\n\n\n
                  • Security Feature:<\/strong> No user involvement, focusing on service security.<\/li>\n<\/ul>\n\n\n\n

                    5. Device Code Grant<\/strong><\/h4>\n\n\n\n
                      \n
                    • Flow:<\/strong> The device (e.g., a smart TV) shows the user a code and a URL. The user then visits the URL on their phone or computer, logs in, and enters the code. Once authorized, the device gets an access token.<\/li>\n\n\n\n
                    • Use Case:<\/strong> Perfect for devices without a browser or input capabilities<\/strong>, like smart TVs, gaming consoles, or IoT devices<\/strong>.<\/li>\n\n\n\n
                    • Security Feature:<\/strong> Separates the authentication step from the device, preventing credential input on potentially insecure platforms.<\/li>\n<\/ul>\n\n\n\n

                      6. Refresh Token Grant<\/strong><\/h4>\n\n\n\n
                        \n
                      • Flow:<\/strong> After a user has authenticated once and the original access token expires, the client uses a refresh token<\/strong> to obtain a new access token without asking the user to log in again<\/strong>.<\/li>\n\n\n\n
                      • Use Case:<\/strong> Ideal for apps requiring long-lived sessions<\/strong>, like mobile apps or web apps where users shouldn\u2019t have to log in every hour.<\/li>\n\n\n\n
                      • Security Feature:<\/strong> Helps reduce login frequency while keeping sessions secure. Refresh tokens are typically stored securely and used only when necessary.<\/li>\n<\/ul>\n\n\n\n
                        \n\n\n\n

                        Common OAuth Attacks and Mitigations<\/strong><\/h3>\n\n\n\n

                        The previous section covered all the basics that you need to know about OAuth. Now let’s understand what are the common oauth attacks and how to best protect against them.<\/p>\n\n\n\n

                        Here\u2019s a brief and easy-to-understand explanation<\/strong> of each OAuth-related attack along with real-world examples<\/strong> and short mitigations<\/strong>:<\/h4>\n\n\n\n
                        \n\n\n\n

                        1. Phishing Attacks<\/strong><\/h3>\n\n\n\n

                        What Happens:<\/strong>
                        Attackers create fake login pages that mimic services like Google or Facebook to steal user credentials or authorization codes.<\/p>\n\n\n\n

                        Example:<\/strong>
                        You get an email asking to \u201clog into your account,\u201d which redirects to a lookalike Google OAuth login page.<\/p>\n\n\n\n

                        Mitigation:<\/strong><\/p>\n\n\n\n

                          \n
                        • Only trust OAuth URLs over HTTPS<\/li>\n\n\n\n
                        • Train users to verify URLs carefully<\/li>\n<\/ul>\n\n\n\n
                          \n\n\n\n

                          2. Token Leakage<\/strong><\/h3>\n\n\n\n

                          What Happens:<\/strong>
                          Access tokens leak through browser history, referrer headers, or insecure local storage (e.g., localStorage<\/code> in SPAs).<\/p>\n\n\n\n

                          Example:<\/strong>
                          A user logs in via OAuth, and the token is logged in browser dev tools or passed in URL parameters.<\/p>\n\n\n\n

                          Mitigation:<\/strong><\/p>\n\n\n\n

                            \n
                          • Use Authorization Code Grant (not Implicit Grant)<\/li>\n\n\n\n
                          • Always use HTTPS<\/li>\n<\/ul>\n\n\n\n
                            \n\n\n\n

                            3. Token Replay Attack<\/strong><\/h3>\n\n\n\n

                            What Happens:<\/strong>
                            An attacker captures a token (via proxy or insecure app) and reuses it to impersonate a user.<\/p>\n\n\n\n

                            Example:<\/strong>
                            An attacker sniffs an access token on a public Wi-Fi and uses it to access user data.<\/p>\n\n\n\n

                            Mitigation:<\/strong><\/p>\n\n\n\n

                              \n
                            • Use short-lived tokens<\/strong><\/li>\n\n\n\n
                            • Bind tokens to client using MTLS or DPoP<\/strong><\/li>\n\n\n\n
                            • Validate token sessions<\/li>\n<\/ul>\n\n\n\n
                              \n\n\n\n

                              4. \ud83c\udfad Cross-Site Request Forgery (CSRF)<\/strong><\/h3>\n\n\n\n

                              What Happens:<\/strong>
                              An attacker tricks a logged-in user into unknowingly sending a valid OAuth authorization request.<\/p>\n\n\n\n

                              Example:<\/strong>
                              You\u2019re logged into an app, and visiting a malicious site silently triggers an OAuth request in your name. Or you as a victim unwillingly add attacker’s account as part of adding 3rd party integrations.<\/p>\n\n\n\n

                              Mitigation:<\/strong><\/p>\n\n\n\n

                                \n
                              • Use state<\/code> parameter to link request to session<\/li>\n\n\n\n
                              • Add CSRF tokens in requests<\/li>\n<\/ul>\n\n\n\n
                                \n\n\n\n

                                5. Authorization Code Interception<\/strong><\/h3>\n\n\n\n

                                What Happens:<\/strong>
                                A malicious app intercepts the authorization code (sent via redirect) and uses it to fetch a token.<\/p>\n\n\n\n

                                Example:<\/strong>
                                An attacker installs malware on your device that catches the OAuth redirect and steals the code.<\/p>\n\n\n\n

                                Mitigation:<\/strong><\/p>\n\n\n\n

                                  \n
                                • Use PKCE<\/strong> (Proof Key for Code Exchange)<\/li>\n\n\n\n
                                • Enforce HTTPS<\/strong> for all traffic<\/li>\n<\/ul>\n\n\n\n
                                  \n\n\n\n

                                  6. Access Token Manipulation<\/strong><\/h3>\n\n\n\n

                                  What Happens:<\/strong>
                                  Attackers try to modify or forge access tokens (especially if JWTs are used) to gain unauthorized access.<\/p>\n\n\n\n

                                  Example:<\/strong>
                                  Someone tampers with the JWT payload to escalate privileges from read<\/code> to admin<\/code>.<\/p>\n\n\n\n

                                  Mitigation:<\/strong><\/p>\n\n\n\n

                                    \n
                                  • Sign JWTs and verify signatures<\/li>\n\n\n\n
                                  • Validate token claims on server<\/li>\n<\/ul>\n\n\n\n
                                    \n\n\n\n

                                    7. Open Redirect Vulnerabilities<\/strong><\/h3>\n\n\n\n

                                    What Happens:<\/strong>
                                    An attacker exploits redirect URIs to send users to a malicious site after OAuth login.<\/p>\n\n\n\n

                                    Example:<\/strong>
                                    After Google login, instead of returning to the original site, the user is redirected to evil.com<\/code>.<\/p>\n\n\n\n

                                    Mitigation:<\/strong><\/p>\n\n\n\n

                                      \n
                                    • Whitelist<\/strong> redirect URIs<\/li>\n\n\n\n
                                    • Avoid wildcards (*<\/code>) in URI patterns<\/li>\n<\/ul>\n\n\n\n
                                      \n\n\n\n

                                      8. Scope Abuse<\/strong><\/h3>\n\n\n\n

                                      What Happens:<\/strong>
                                      A client app requests more permissions than needed, increasing the blast radius if compromised.<\/p>\n\n\n\n

                                      Example:<\/strong>
                                      A fitness app asks for full Gmail access instead of just step count.<\/p>\n\n\n\n

                                      Mitigation:<\/strong><\/p>\n\n\n\n

                                        \n
                                      • Follow least privilege<\/strong> principle<\/li>\n\n\n\n
                                      • Limit scopes at the user and server level<\/li>\n<\/ul>\n\n\n\n
                                        \n\n\n\n

                                        9. Refresh Token Abuse<\/strong><\/h3>\n\n\n\n

                                        What Happens:<\/strong>
                                        Stolen refresh tokens allow attackers to get new access tokens repeatedly, bypassing expiration.<\/p>\n\n\n\n

                                        Example:<\/strong>
                                        An attacker gets hold of a long-lived refresh token and keeps renewing access.<\/p>\n\n\n\n

                                        Mitigation:<\/strong><\/p>\n\n\n\n

                                          \n
                                        • Rotate<\/strong> refresh tokens after each use<\/li>\n\n\n\n
                                        • Set strict expiration and reuse limits<\/strong><\/li>\n<\/ul>\n\n\n\n

                                          OAuth is a powerful protocol that enables seamless and secure delegated access\u2014but with great power comes great responsibility. As developers and security professionals, it’s crucial to understand not just how OAuth works, but how attackers can abuse its flows. From phishing and token leakage to code interception and scope abuse, each vulnerability can have serious consequences if left unchecked. By learning the fundamentals, choosing the right grant types, and applying practical mitigations like PKCE, token binding, and strict scope management, you can drastically reduce the attack surface of your applications.<\/p>\n\n\n\n

                                          Remember: secure design isn\u2019t just about compliance\u2014it\u2019s about protecting real users from real threats. Keep learning, stay curious, and keep building safer systems.<\/p>\n\n\n\n

                                          <\/p>\n","protected":false},"excerpt":{"rendered":"

                                          OAuth is everywhere\u2014from signing into your favorite apps using Google or GitHub to enabling secure access between APIs. But while OAuth is incredibly powerful, it\u2019s also one of the most misunderstood and misconfigured components in modern applications. And that\u2019s exactly why knowing its fundamentals isn’t optional\u2014it’s critical. Misconfigurations in OAuth can open doors to serious […]<\/p>\n","protected":false},"author":1,"featured_media":1853,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ocean_post_layout":"","ocean_both_sidebars_style":"","ocean_both_sidebars_content_width":0,"ocean_both_sidebars_sidebars_width":0,"ocean_sidebar":"","ocean_second_sidebar":"","ocean_disable_margins":"enable","ocean_add_body_class":"","ocean_shortcode_before_top_bar":"","ocean_shortcode_after_top_bar":"","ocean_shortcode_before_header":"","ocean_shortcode_after_header":"","ocean_has_shortcode":"","ocean_shortcode_after_title":"","ocean_shortcode_before_footer_widgets":"","ocean_shortcode_after_footer_widgets":"","ocean_shortcode_before_footer_bottom":"","ocean_shortcode_after_footer_bottom":"","ocean_display_top_bar":"default","ocean_display_header":"default","ocean_header_style":"","ocean_center_header_left_menu":"","ocean_custom_header_template":"","ocean_custom_logo":0,"ocean_custom_retina_logo":0,"ocean_custom_logo_max_width":0,"ocean_custom_logo_tablet_max_width":0,"ocean_custom_logo_mobile_max_width":0,"ocean_custom_logo_max_height":0,"ocean_custom_logo_tablet_max_height":0,"ocean_custom_logo_mobile_max_height":0,"ocean_header_custom_menu":"","ocean_menu_typo_font_family":"","ocean_menu_typo_font_subset":"","ocean_menu_typo_font_size":0,"ocean_menu_typo_font_size_tablet":0,"ocean_menu_typo_font_size_mobile":0,"ocean_menu_typo_font_size_unit":"px","ocean_menu_typo_font_weight":"","ocean_menu_typo_font_weight_tablet":"","ocean_menu_typo_font_weight_mobile":"","ocean_menu_typo_transform":"","ocean_menu_typo_transform_tablet":"","ocean_menu_typo_transform_mobile":"","ocean_menu_typo_line_height":0,"ocean_menu_typo_line_height_tablet":0,"ocean_menu_typo_line_height_mobile":0,"ocean_menu_typo_line_height_unit":"","ocean_menu_typo_spacing":0,"ocean_menu_typo_spacing_tablet":0,"ocean_menu_typo_spacing_mobile":0,"ocean_menu_typo_spacing_unit":"","ocean_menu_link_color":"","ocean_menu_link_color_hover":"","ocean_menu_link_color_active":"","ocean_menu_link_background":"","ocean_menu_link_hover_background":"","ocean_menu_link_active_background":"","ocean_menu_social_links_bg":"","ocean_menu_social_hover_links_bg":"","ocean_menu_social_links_color":"","ocean_menu_social_hover_links_color":"","ocean_disable_title":"default","ocean_disable_heading":"default","ocean_post_title":"","ocean_post_subheading":"","ocean_post_title_style":"","ocean_post_title_background_color":"","ocean_post_title_background":0,"ocean_post_title_bg_image_position":"","ocean_post_title_bg_image_attachment":"","ocean_post_title_bg_image_repeat":"","ocean_post_title_bg_image_size":"","ocean_post_title_height":0,"ocean_post_title_bg_overlay":0.5,"ocean_post_title_bg_overlay_color":"","ocean_disable_breadcrumbs":"default","ocean_breadcrumbs_color":"","ocean_breadcrumbs_separator_color":"","ocean_breadcrumbs_links_color":"","ocean_breadcrumbs_links_hover_color":"","ocean_display_footer_widgets":"default","ocean_display_footer_bottom":"default","ocean_custom_footer_template":"","ocean_post_oembed":"","ocean_post_self_hosted_media":"","ocean_post_video_embed":"","ocean_link_format":"","ocean_link_format_target":"self","ocean_quote_format":"","ocean_quote_format_link":"post","ocean_gallery_link_images":"on","ocean_gallery_id":[],"footnotes":""},"categories":[2,440,455,321],"tags":[310,442,342,344,457,456],"class_list":["post-1845","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-information-security","category-mitigations","category-oauth","category-owasp-top-10","tag-attacks","tag-mitigations","tag-oauth","tag-state","tag-token-leaks","tag-tokens","entry","has-media"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/posts\/1845"}],"collection":[{"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/comments?post=1845"}],"version-history":[{"count":4,"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/posts\/1845\/revisions"}],"predecessor-version":[{"id":1852,"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/posts\/1845\/revisions\/1852"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/media\/1853"}],"wp:attachment":[{"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/media?parent=1845"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/categories?post=1845"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shreyapohekar.com\/blogs\/wp-json\/wp\/v2\/tags?post=1845"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}