What is OAuth 2.0 and how does it connect applications without sharing passwords?

Published on 2026-10-20 by frfrand

OAuth 2.0 explicado con un ejemplo de permisos delegados, scopes, redirecciones y diferencias entre autorización e identidad.

OAuth 2.0 is a framework for granting limited access to an application without directly handing over your account credentials for another service. That's why it appears when you want to link a calendar, storage, or external system with a tool you use.

It's not just a "Sign in with Google" button. OAuth flows also exist to authorize access to APIs.

The valet example

Imagine you leave your car at a parking lot. Instead of giving all your house keys to the staff, you hand over a key that works for a specific function.

OAuth seeks a similar goal: authorizing specific operations for a certain scope and conditions, without sharing the main password with the application requesting access.

The comparison is imperfect, because tokens can be copied if they leak and each provider sets its own rules.

How it usually works

An application wants to query your calendar. It redirects you to the service that manages the account. There you log in if necessary and review what access is being requested.

If you authorize it, the application can receive an authorization code and securely exchange it for access credentials according to the implemented flow. The obtained token allows calling an API within the granted permissions.

In the modern authorization code flow, PKCE is commonly used, which adds important protection, especially for public clients.

What is a scope?

A scope indicates a defined authorization scope by the service. For example, an integration may request to read calendar events instead of requesting access to all resources.

Requesting fewer permissions is a good practice. It makes no sense to request file deletion capability when the integration only needs to list names.

But scopes do not replace all API security checks. Each provider must additionally validate which actual resources the holder can consult.

OAuth is not the same as OpenID Connect

A common confusion appears here. OAuth focuses on delegated authorization. OpenID Connect uses OAuth 2.0 as a base and adds an identity layer so that an application can authenticate the user.

That is why it is not advisable to take an access token from any service and use it as if it by itself demonstrated a person's identity to your application.

What risks exist?

A poorly validated redirect URL may allow sending codes to an improper destination. A stolen token may be used within its scope while it remains valid. Requesting excessive permissions increases the impact of a compromise.

Modern implementations need to protect state when appropriate, use PKCE in the appropriate flows, validate redirects, and store tokens securely. It is not enough to copy a URL from a tutorial.

And the refresh token?

Some providers deliver credentials that allow obtaining new access tokens without repeating the entire interaction. Not all flows use them nor do they have the same policies.

They must be especially protected: if someone obtains a valid refresh token, they can extend access according to the provider's rules. It is advisable to check revocation, rotation, and expiration.

A real use case

Imagine an assistant that helps organize meetings and needs to check your availability. With a correct OAuth flow, you can authorize access to your calendar without giving the assistant your main password.

If you stop using that application afterward, you should be able to revoke access from the provider's account when it allows it.

What does it have to do with ArduMaker?

When connecting external accounts or integrating a tool with services managed from ArduMaker, OAuth can be an option when the provider supports it. The goal should be to grant only the necessary capabilities, with explicit and revocable authorization.

In one sentence: OAuth allows delegating scoped access. It does not eliminate the need to protect tokens nor replace a well-designed permissions policy.

Sources: RFC 6749, OAuth 2.0 · RFC 7636, PKCE · OpenID Connect.