OAuth 2.0
OAuth 2.0 is an open standard for delegated authorization (RFC 6749). It allows users to grant an application limited access to their data on another service – without sharing passwords. When a user signs in with Google, GitHub or Microsoft on a Web Apps , an OAuth 2.0 flow runs in the background.
How does OAuth 2.0 work?
OAuth 2.0 defines four roles: Resource Owner (user), Client (application), Authorization Server (e.g., Google) and Resource Server ( API ). The flow: 1. The application redirects the user to the Authorization Server. 2. The user gives consent. 3. The Authorization Server returns an Authorization Code. 4. The application exchanges the code for an Access Token (often a JWT ). 5. The Access Token is used for API requests.
OAuth 2.0 flows at a glance
Authorization Code Flow: standard for server-side applications – the most secure flow. Authorization Code Flow + PKCE: mandatory for single-page applications and mobile apps. Client Credentials Flow: for server-to-server communication without user context. Implicit Flow: deprecated and insecure – no longer recommended. The choice of flow depends on the application type: Server-Side Rendering applications use the Authorization Code Flow, SPAs use PKCE.
OAuth 2.0 vs. OpenID Connect
OAuth 2.0 handles authorization (what may the app do?), not authentication (who is the user?). OpenID Connect (OIDC) builds on OAuth 2.0 and adds an identity layer: a standardized ID Token ( JWT ) containing information about the user. For login functionality (social login, SSO), OIDC is always recommended over OAuth 2.0 alone.
Security in OAuth implementations
PKCE for all public clients (SPAs, mobile apps). State parameter against CSRF attacks. Strictly validate redirect URIs – no wildcards. Tokens in HttpOnly cookies or secure stores, never in localStorage. Restrict scopes to the minimum. Manage client secrets via Secret Management , never in frontend code. Implement Rate Limiting on token endpoints.
How we use it
We use OAuth 2.0 specifically where third-party login is required – such as Google or GitHub login in client web apps. For this, we use django-oauth-toolkit in the Django REST backend with the Authorization Code Flow + PKCE. Client secrets are stored in Secret Management , and redirect URIs are strictly restricted to the production domain. For purely internal authentication, we prefer lightweight JWT flows with Server-Side Validation on every endpoint.