--- id: CP-194 slug: oauth-2-delegated-access-tokens lang: en title: OAuth 2.0 and access tokens description: How OAuth 2.0 gives an application limited access to your account without your password, and how to read the consent screen. canonical_url: https://startbrain.io/cyberpedia/en/articles/oauth-2-delegated-access-tokens/ markdown_url: https://startbrain.io/cyberpedia/en/articles/oauth-2-delegated-access-tokens.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: Brain, "OAuth 2.0 and access tokens", Cyberpedia, 2026. https://startbrain.io/cyberpedia/en/articles/oauth-2-delegated-access-tokens/ (CC BY 4.0) wing: 3 theme: control_access reflex: cr-026 schema: G3 updated: "2026-11-03" translations: en: https://startbrain.io/cyberpedia/en/articles/oauth-2-delegated-access-tokens/ fr: https://startbrain.io/cyberpedia/fr/articles/oauth-2-delegation-acces-jetons/ de: https://startbrain.io/cyberpedia/de/articles/oauth-2-delegierter-zugriff-token/ es: https://startbrain.io/cyberpedia/es/articles/oauth-2-delegacion-acceso-tokens/ sources: - "n": 1 title: Investigate and remediate risky OAuth apps publisher: Microsoft url: https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth accessed: "2026-11-03" - "n": 2 title: Steal Application Access Token, Technique T1528 - Enterprise publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 3 title: Access tokens in the Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens accessed: "2026-11-03" - "n": 4 title: Refresh tokens in the Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens accessed: "2026-11-03" - "n": 5 title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/001/ accessed: "2026-11-03" - "n": 6 title: OAuth2 - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html accessed: "2026-11-03" --- # OAuth 2.0 and access tokens OAuth is an open standard for token-based authentication and authorization. It lets a third-party service use the information in an account without exposing the account holder's password [1]. Take an application that analyzes your calendar to advise you on your organization. It needs access to the calendar, but instead of receiving your credentials, it gets a token, created when you give your consent on a dedicated page [1]. This page is called the consent screen. ## In 30 seconds - Where it happens: many third-party applications installed by users ask for permission to access their data and to sign in on their behalf in other online applications [1]. - What the attacker wants: to get you to grant access to a malicious application, for example after a link received through targeted phishing [2]. - The reflex: before clicking "Accept", check that the permissions requested match the purpose of the application, and refuse if they do not [1]. - If it is already done: an administrator can ban or revoke the application [1]. ## Straight answers ### What happens when I accept a consent screen? The application receives an access token that allows the sharing of specific account information, and only that [1]. The password stays with the account provider. ### What is an access token? It is a credential designed for authorization: it gives access to specific resources on behalf of a user who is already authenticated. Microsoft compares it to keys that open specific doors in a building [3]. Because it grants access, it is sensitive and presents a risk if poorly protected [3]. Its lifetime is limited. On the Microsoft identity platform, the default value is picked at random between 60 and 90 minutes, which is 75 minutes on average [3]. ### What is a refresh token? A refresh token is used to obtain a new pair of tokens when the access token expires. The client receives it at the same time as the access token [4]. It lasts longer: by default 24 hours for single-page applications and for those that use the one-time email code authentication flow, and 90 days in all other scenarios, on the Microsoft platform [4]. The application can thus keep working in the background without asking for your agreement at each expiry. ### Why do attackers want these tokens? A stolen token lets someone act with the rights of the account. MITRE ATT&CK describes attackers who use stolen tokens in place of login credentials [5]. The refresh token makes the risk worse: if it is stolen, the attacker obtains new access tokens without involving the user [2]. ### Can an application's access be removed? Yes. On the administration side, an application can be banned or revoked from the OAuth apps page, and a policy can automate revocation [1]. On the token side, the service can revoke a refresh token before it expires, for example after a password change or an action by the user or the administrator [4]. The effects vary depending on the type of token and the change made [4]. ## How it works Three actors are involved. The client is the application that asks for access. The authorization server issues the tokens after authenticating the data owner and obtaining their consent. The resource server hosts the data and accepts requests that come with a token [6]. The access token replaces the various credentials (a username and password, for example) with a single item that the resource server understands. It can therefore have a short lifetime [6]. The refresh token makes it possible to obtain a new one, with identical or narrower rights: an access token can have a shorter lifetime and fewer permissions than those granted by the owner [6]. The most common token is the bearer token: anyone who holds it can use it. OWASP therefore recommends limiting it, preferably, to a single resource server, to reduce the damage in case of a leak [6]. The application, for its part, must treat the token as an opaque string: only the targeted API should read its content [3]. ## What you do Faced with a consent screen, a few checks are enough. - Read the request before accepting it. Users often click "Accept" without examining the details, including the permissions granted [1]. - Compare the permissions with the purpose of the application. An application should only ask for permissions related to its purpose, and Microsoft gives the example of a clock application with full access to all mailboxes, which does not match its purpose [1]. - Be wary of the heaviest permissions. MITRE ATT&CK points out that offline access and access to read emails should raise more suspicion, because attackers can use online service APIs to look there for credentials and sensitive communications [2]. - Look at the redirect address. If it is misspelled or forms a complicated string of words around an expected service, the site is probably trying to imitate a real service [2]. - Prefer common applications. The more widespread an application is, within the organization and online, the more likely it is to be safe [1]. - Refuse an application you do not recognize. MITRE ATT&CK recommends training users not to authorize unknown third-party applications [2]. - An administrator can investigate suspicious applications and remove them [2]. ## Pitfalls ### The fake consent screen The attacker registers an application with the authorization server, then sends a targeted phishing link to get the victim to grant it access [2]. One example given by Microsoft: a consent page can look legitimate to an average user, whereas "Google APIs Explorer" has no reason to ask Google itself for permissions. The application can therefore be a phishing attempt unrelated to Google [1]. Reassuring names are common. MITRE ATT&CK notes that the APT28 group used malicious applications posing as "Google Defender", "Google Email Protection" and "Google Scanner" to Gmail users, and as "Delivery Service" and "McAfee Email Protection" to Yahoo users [2]. ### The token that lasts Once the token is granted, the application can obtain potentially long-lasting access to the account's functions [2]. With a refresh token that allows background access, an attacker can, for example, search emails and enumerate contacts [5]. Changing your password does not always solve the problem: according to Microsoft's table, some tokens stay active after a password change by the user [4]. ### The token stolen without asking you anything Token theft does not always go through a consent. MITRE ATT&CK also cites tokens stolen in container environments or development pipelines, where they are used to authenticate to other services [2]. The Kali365 program is described as having obtained OAuth access and refresh tokens by tricking victims into approving device authorization requests initiated by the attacker [2]. ### The forgotten application An application authorized one day stays connected as long as nobody removes it. Microsoft recommends spotting applications whose last authorization date is not recent: they may no longer be needed [1]. MITRE ATT&CK asks administrators for an audit of all OAuth applications and the permissions granted, followed by periodic audits, with investigation and removal of suspicious applications [2]. On the employee side, this comes down to a simple habit: go back from time to time over the list of applications connected to your account and report those you do not recognize. ## Sources 1. Microsoft, "Investigate and remediate risky OAuth apps". https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth (accessed 3 November 2026) 2. MITRE ATT&CK, "Steal Application Access Token, Technique T1528 - Enterprise". https://attack.mitre.org/techniques/T1528/ (accessed 3 November 2026) 3. Microsoft, "Access tokens in the Microsoft identity platform". https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens (accessed 3 November 2026) 4. Microsoft, "Refresh tokens in the Microsoft identity platform". https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens (accessed 3 November 2026) 5. MITRE ATT&CK, "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise". https://attack.mitre.org/techniques/T1550/001/ (accessed 3 November 2026) 6. OWASP, "OAuth2 - OWASP Cheat Sheet Series". https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html (accessed 3 November 2026) --- Original source: Cyberpedia, the public cybersecurity and AI encyclopedia published by Brain. Canonical version: https://startbrain.io/cyberpedia/en/articles/oauth-2-delegated-access-tokens/ You may reuse this text freely under the CC BY 4.0 license (https://creativecommons.org/licenses/by/4.0/), provided you credit "Brain, Cyberpedia" with a link to the canonical URL above.