---
title: "OAuth | Skills We Assign For | Azendo"
description: "OAuth 2.0 in practice — flow selection, token handling, PKCE, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/oauth/"
---

[Skills](https://azendo.co/skills/) APIs and integration 

# OAuth.

OAuth 2.0 is the standard authorisation framework for delegated access: a user grants an application limited access to their resources without sharing credentials, through tokens with defined scopes and lifetimes.

## Where OAuth fits on a long engagement.

Flow selection is the decision that determines whether an implementation is secure. Authorisation code with PKCE is correct for web and mobile applications; implicit flow is deprecated and still present in older code; client credentials is for service-to-service with no user involved. Using the wrong one is a security defect rather than a style choice.

Token storage is where browser implementations most often fail. Access tokens in local storage are readable by any script on the page, which makes a cross-site scripting flaw into full account compromise. Memory plus an HTTP-only refresh cookie is the safer pattern and is more work.

## What an assigned team does with OAuth.

Scope discipline is routinely poor. Applications request broad permissions because it avoids a second consent later, which means a compromised token grants far more than the application needed.

Requesting the minimum and escalating when required is the correct approach, and it is the standard held by assigned specialists under [outsource software development services](https://azendo.co/services/software-development/).

## What we use OAuth for.

* The correct flow for the client type Authorisation code with PKCE rather than a deprecated flow carried forward.
* Tokens stored safely Memory and HTTP-only cookies, so a scripting flaw is not account compromise.
* Minimum scopes requested Narrow permissions escalated on need, limiting what a stolen token grants.

## How OAuth capacity is assigned.

Authentication work is assigned inside development capacity, with flow and token handling reviewed as security decisions rather than integration details.

## Roles we assign OAuth for

* [Integration Engineer AI automation engineering](https://azendo.co/services/ai-automation-engineering/integration-engineer/)
* [Workflow Automation Specialist AI automation engineering](https://azendo.co/services/ai-automation-engineering/workflow-automation-specialist/)

## Service lines it sits in

* [AI automation engineering](https://azendo.co/services/ai-automation-engineering/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in apis and integration

* [REST — skill we assign for](https://azendo.co/skills/rest/)
* [GraphQL — skill we assign for](https://azendo.co/skills/graphql/)
* [gRPC — skill we assign for](https://azendo.co/skills/grpc/)
* [webhooks — skill we assign for](https://azendo.co/skills/webhooks/)
* [Kafka — skill we assign for](https://azendo.co/skills/kafka/)
* [API design — skill we assign for](https://azendo.co/skills/api-design/)
* [message queues — skill we assign for](https://azendo.co/skills/message-queues/)
* [FastAPI — skill we assign for](https://azendo.co/skills/fastapi/)

## Tell us what your roadmap needs OAuth for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)