{"id":1551,"date":"2026-06-03T22:34:58","date_gmt":"2026-06-03T22:34:58","guid":{"rendered":"https:\/\/blog.scilabs.mx\/en\/?p=1551"},"modified":"2026-06-03T22:34:58","modified_gmt":"2026-06-03T22:34:58","slug":"when-mfa-is-not-enough-tokens-cookies-and-api-keys-as-the-new-access-keys","status":"publish","type":"post","link":"https:\/\/blog.scilabs.mx\/en\/2026\/06\/03\/when-mfa-is-not-enough-tokens-cookies-and-api-keys-as-the-new-access-keys\/","title":{"rendered":"When MFA Is Not Enough: Tokens, Cookies, and API Keys as the New Access Keys"},"content":{"rendered":"\n

In recent years, Multi-Factor Authentication \u2014better known as MFA<\/a> \u2014 has become one of the main recommendations for protecting corporate accounts, web applications, cloud services, development platforms, and administrative access to critical infrastructure. The logic is simple: even if an adversary obtains the password, they will need a second mechanism to successfully gain access.<\/p>\n\n\n\n

In this context, application security testing, architecture reviews, and incident investigations<\/a>, as well as research conducted by the Cyber Threat Research team at the Scitum Innovation Center, show an increasingly frequent pattern: many modern attacks no longer seek to compromise MFA, but to bypass it entirely. To do so, adversaries target the elements generated after the user has already authenticated successfully: session cookies<\/a>, OAuth 2.0 tokens<\/a>, SSO (Single Sign-On)<\/a>, JWT (JSON Web Token)<\/a>, access and refresh tokens<\/a>, and API keys<\/a>.<\/p>\n\n\n\n

These elements function as access artifacts. If they are valid, the application or API assumes that whoever presents them is the authorized user, application, or service. Therefore, when an adversary obtains them, they can access protected resources without knowing the password and without going through multifactor authentication again.<\/p>\n\n\n\n

The objective of this article is to explain, from a technical perspective, why the theft or abuse of tokens, cookies, OAuth, and API keys represents a design problem in many current architectures, how adversaries are exploiting these weaknesses in recent attacks, and what controls organizations can implement to reduce this risk.<\/p>\n\n\n\n

The problem: identity also exists after login<\/strong><\/strong><\/h6>\n\n\n\n

When a user logs in to an application, the following usually occurs:<\/p>\n\n\n\n

\"\"
Figure 1 Typical authentication flow<\/figcaption><\/figure>\n\n\n\n

This prevents the user from having to enter a password and MFA for every click or interaction with the application, improving usability and the user’s browsing experience. The problem arises when those elements are treated as portable, reusable, and long-lived values.<\/p>\n\n\n\n

In practice, a session object can represent different risks, such as:<\/p>\n\n\n\n

Element<\/strong><\/td>Common use<\/strong><\/strong><\/td>Main risk<\/strong><\/strong><\/td><\/tr>
Session cookie<\/td>Keep the user authenticated in the browser<\/td>If stolen, it enables session hijacking<\/a> or cookie hijacking<\/a>.<\/td><\/tr>
Access token<\/td>Authorize calls to APIs or endpoints<\/span><\/span><\/td>If leaked, it enables access to resources within the authorized scope<\/td><\/tr>
Refresh token<\/td>Renew access tokens without requiring login again<\/td>If stolen, it extends the duration of the session stolen by the adversary<\/td><\/tr>
API key<\/td>Authenticate scripts, services, or integrations<\/td>If exposed, it enables direct abuse of available endpoints<\/td><\/tr>
OAuth grant<\/td>Authorize a third-party application<\/td>If compromised, it can open a persistent access path that could culminate in a supply chain attack<\/td><\/tr><\/tbody><\/table>
Table 1 Uses vs risks in session elements<\/figcaption><\/figure>\n\n\n\n

The key point is this: MFA strengthens authentication, but it does not always protect the subsequent use of the elements issued after access is granted.<\/p>\n\n\n\n

Therefore, a useful question for evaluating an application’s design is not only:<\/p>\n\n\n\n

Does the application have MFA?<\/p>\n\n\n\n

But also:<\/p>\n\n\n\n

What can an adversary do if they obtain a valid cookie, token, refresh token, or API key?<\/p>\n\n\n\n

\n\n\n\n

Session Cookie Theft: the access that the browser stores for us<\/h3>\n\n\n\n

Session cookies are one of the most common ways to keep a user authenticated in a web application. Once the user logs in, the server sends a cookie to the browser. In subsequent requests, the browser automatically includes it in the web request headers so that the server recognizes the session as valid.<\/p>\n\n\n\n

From the user’s perspective, this is transparent. From the server’s perspective, the cookie represents an already authenticated session.<\/p>\n\n\n\n

The problem is that many applications do not validate enough context around that cookie. If a malicious user manages to obtain it, they can attempt to reuse it from another browser, another device, or even another region.<\/p>\n\n\n\n

These attacks usually look like this:<\/p>\n\n\n\n

\"\"
Figure 2 Cookie theft attack flow<\/figcaption><\/figure>\n\n\n\n
Design lesson<\/strong><\/strong><\/h6>\n\n\n\n

MFA protects the user in the event of username and password theft; however, the system trusts the authentication element generated after access. In other words, the second factor has already been provided by the victim. The adversary does not need to repeat it if the application accepts the cookie as sufficient proof of authentication.<\/p>\n\n\n\n

In this scenario, OWASP proposes four crucial elements<\/a> to mitigate this failure:<\/p>\n\n\n\n