What OAuth 2.0 is and why it is needed
OAuth 2.0 is an authorization protocol, not authentication. It lets another service act on behalf of the user without asking for the password. For example, when a user signs into Sayt.uz with a Google account, Sayt.uz does not know the Google password and only gets the email and profile data via the access token issued by Google.
The protocol has four main participants: resource owner (user), client (application), authorization server (Google) and resource server (Google API). This separation provides security: the application never sees the user password, and the user can revoke access at any time.
Authorization code flow
The most secure and standard flow is the authorization code flow. The user is redirected to a Google page and signs in there. Google issues a special authorization code and returns the user to the application. The application sends this code from its server together with the client_secret to Google and receives an access token in return.
The advantage of this flow is that the access token never travels through the browser; it is exchanged only between backend servers. This protects against XSS and token leaks. At Sayt.uz all social login flows run through this exact pattern.
PKCE โ protection for public clients
Mobile and SPA apps cannot store client_secret securely because they run on the user device. To solve this there is the PKCE standard (Proof Key for Code Exchange). The app generates a random code_verifier and sends its SHA256 hash (code_challenge) along with the authorization request.
During token exchange the app sends the original code_verifier again. Google hashes it and compares it to the initial code_challenge. If they match, the token is issued. Even if an attacker steals the authorization code, without code_verifier it is useless.
Refresh tokens and session duration
Access token is short-lived (1 hour), refresh token is long-lived (30-90 days). To avoid forcing users to log in every hour, the app uses the refresh token to automatically obtain a new access token. The refresh token must be stored only on the backend and never exposed to the browser in plain form.
In Sayt.uz practice refresh token rotation is in place: with every refresh the old token is revoked and a new one issued. If a revoked token is reused, it is a theft signal โ all user sessions are forcibly closed and an email warning is sent.
Google and Facebook integration
Each provider has its own authorization endpoint, token endpoint and userinfo endpoint. For Google these are accounts.google.com and www.googleapis.com, for Facebook โ graph.facebook.com. Scope parameters also differ: Google standard is openid profile email, Facebook uses public_profile email.
At Sayt.uz a unified interface is built for providers: each provider implements its adapter with the same getAuthUrl, getAccessToken and getUserInfo methods. This makes adding new providers easy without changing the main login logic.
Sayt.uz practice
OAuth integration at Sayt.uz is as follows: authorization code flow for all providers, PKCE mandatory for public clients, state parameter for CSRF protection, nonce for replay attack protection. Access token is in Redis for 1 hour, refresh token is encrypted in PostgreSQL. Every login and refresh is written to the audit log.