OAuth 2.0

OAuth 2.0 is a standard allowing an application to access a user's resources without knowing their password. This access is granted using time-limited tokens.

How it works

An application requests access to a person's mailbox or calendar. The person logs in to the service provider and consents to the access. The provider then issues an access token containing specific permissions, which are called scopes. A refresh token is often included, allowing the application to obtain new access tokens. OpenID Connect builds on OAuth and adds user authentication functionality.

As a practical example, an employee receives an email with a link to a supposed PDF app. She consents to the app accessing her mailbox. In reality, the app belongs to an attacker. The attacker can now read and send emails, even after a password change. The SOC detects the newly authorised app with its extensive permissions and revokes its access.

What to look out for

• Restrict which apps employees can authorise themselves.
• Require admin approval for apps with extensive permissions.
• Regularly review the list of authorised applications.
• Changing a password does not always revoke OAuth tokens. Revoke the consent separately.
• Keep token validity periods as short as is practical.

Why it matters

Attacks via OAuth consents can bypass passwords and MFA. The consent request appears harmless to the user. However, the attacker gains persistent access which is difficult to detect.

Typical mistakes

A common mistake is allowing all employees to authorise any app. Another is in-house applications that store tokens insecurely, for example in the browser or in logs.

Relevance for the SOC

New application consents, unusual scopes, and access by apps from external tenants are important signals. This activity requires monitoring within the identity provider.

How we implement it

We monitor application consents and token usage in your identity provider. We block suspicious apps and revoke their tokens within the agreed mandate.