What is OAuth?
OAuth, Open Authorization, is the open standard protocol for delegated authorisation. It lets one application access resources or perform actions on behalf of a user in another application without the user sharing their password. The current widely-deployed version, OAuth 2.0, is the protocol behind familiar flows like "Sign in with Google," "Connect Calendar," and "Authorise Payment."
The core mechanism: the user authorises a specific application with specific scopes (read calendar, charge payment), and the authorising service issues a token. The application uses the token to make API calls within the granted scope. The user can revoke access at any time without changing their password. If the application is breached, only the token is exposed, not the user's primary credentials.
For Indian solar SaaS, OAuth 2.0 is the standard for integration. Connecting a solar CRM to Google Calendar for site visits, to Razorpay for payments, to Zoho Books for accounting, all use OAuth 2.0. Partner integrations expected by larger commercial customers require OAuth.
Why OAuth matters for solar SaaS
For users, OAuth means safer and easier integrations. No more sharing Gmail passwords with third-party tools. No more remembering which apps have which credentials. Authorisation is explicit, scoped, and revocable.
For SaaS vendors, OAuth is the modern integration standard. Customers expect to connect their existing tools to your product without security compromise. Vendors that do not support OAuth integration lose deals to those that do.
For DPDP compliance, OAuth-based integration aligns with consent-driven data access. Users explicitly authorise specific scopes; access is revocable; tokens have limited lifetime. These properties support data protection obligations.
How an OAuth flow proceeds
- User intends to integrate. Clicks "Connect" in App A.
- Redirect to App B. User browser sent to App B's authorisation endpoint.
- User authentication. User logs into App B if not already.
- Consent screen. User reviews requested scopes.
- User consents. Or denies.
- Authorisation code. App B sends short-lived code to App A.
- Token exchange. App A exchanges code for access and refresh tokens.
- API calls. App A uses access token to call App B's API.
- Token refresh. When access token expires, refresh token gets new one.
- Revocation. User can revoke from App B's settings anytime.
Benefits of OAuth-based integration
- Security. Passwords not shared.
- Scoped access. Minimum necessary permissions.
- Revocable. User controls access.
- Token expiry. Breach blast radius limited.
- Industry standard. Expected by partner customers.
- User experience. One-click integration.
- DPDP alignment. Consent-driven data access.
Limitations and challenges
Implementation complexity. Token handling, refresh, revocation.
State parameter for CSRF. Often forgotten.
Scope creep. Apps request excessive scopes.
Token storage security. Server-side encryption needed.
Vendor variation. Each provider's OAuth implementation differs slightly.
Multi-tenancy. Token-per-user complications in B2B.
OAuth integrations for Indian solar SaaS
| Service | Typical OAuth use |
|---|---|
| Google Calendar / Outlook | Site visit scheduling |
| Razorpay / Cashfree | Payment authorisation |
| Zoho Books / Tally Cloud | Accounting data sync |
| Google Drive / Dropbox | Document storage |
| WhatsApp Business API (via BSP) | Messaging access |
| Customer portal social login | 'Sign in with Google' |
Quick facts
| Full form | Open Authorization |
|---|---|
| Current version | OAuth 2.0 |
| RFC | RFC 6749 (core), RFC 7636 (PKCE) |
| Token types | Access (short-lived), refresh (longer) |
| Common scopes | Read, write, admin per resource type |
| Alternative | API keys (for server-to-server) |
| Related | SSO, API, SAML |
Common mistakes about OAuth
- Storing tokens client-side. Security risk.
- Skipping state parameter. CSRF vulnerability.
- Requesting excessive scopes. Privacy concern.
- No refresh handling. Broken UX.
- Treating refresh token as access. Different lifetimes.
- Hardcoding redirect URI. Inflexible.
- Confusing OAuth with SSO. Related but different.
- No token revocation handling. Stale tokens.
Key takeaways
- OAuth is the standard for delegated authorisation between apps.
- OAuth 2.0 is the current widely-used version.
- User authorises specific scopes without sharing password.
- Access tokens are short-lived; refresh tokens longer.
- Expected standard for Indian solar SaaS integrations.
- Supports DPDP consent-driven access patterns.
- Implementation requires care: token storage, state, scope discipline.
Frequently Asked Questions
What is OAuth?
OAuth (Open Authorization) is the open standard for delegated authorisation that lets one application access resources on behalf of a user in another application without sharing the user's password. OAuth 2.0, the current widely-used version, is the protocol behind 'Sign in with Google' and similar flows.
How does OAuth work?
User wants App A to access data in App B. App A redirects user to App B's login. User logs in and consents to specific scopes. App B issues App A an access token with limited scope and expiry. App A uses the token to call App B's API. User's password is never shared with App A.
What is the difference between OAuth and password sharing?
Password sharing gives full account access. OAuth gives scoped, revocable access via tokens. If App A is breached, only the OAuth token is exposed, not the user's password. User can revoke App A's access without changing password.
What are OAuth scopes?
Scopes are the specific permissions a token grants. For Google Calendar OAuth: read events, create events, delete events. User consents to specific scopes during authorisation. Apps should request minimum necessary scopes (principle of least privilege).
What is the OAuth flow for a solar CRM?
A solar CRM connects to Google Calendar via OAuth: user clicks 'Connect Calendar' → redirects to Google login → user consents to calendar scopes → Google issues token → CRM uses token to create site-visit appointments. Same pattern for Zoho Books, Razorpay, WhatsApp Business connections.
What is OAuth 2.0 vs OAuth 1.0?
OAuth 2.0 is the current standard, simpler than 1.0 and more widely adopted. OAuth 1.0 used cryptographic signatures; 2.0 uses bearer tokens (simpler but requires HTTPS). Solar CRM integrations use OAuth 2.0.
What is an access token?
A short-lived credential (typically 1 hour) granting specific scoped access. The access token is sent in API request headers. When it expires, the app uses a refresh token (longer-lived) to get a new access token.
What is a refresh token?
A longer-lived credential (days to indefinite) used to obtain new access tokens without re-asking user consent. Refresh tokens must be stored securely server-side; if leaked, the attacker has indefinite access until user revokes.
Is OAuth secure?
Yes when implemented correctly. Common implementation pitfalls include: storing tokens in client-side code (insecure), missing state parameter (CSRF risk), requesting excessive scopes (privacy issue), no token refresh handling (broken UX). Best practice frameworks reduce these risks.
What is OAuth used for in Indian solar SaaS?
Google and Microsoft calendar integration, Razorpay/Cashfree payment authorisation, Zoho/Tally accounting integration, WhatsApp Business API access (where applicable), social login for customer portals, Google Drive for document sharing.
Does OAuth replace passwords?
Not entirely. OAuth allows users to authorise third-party apps without sharing passwords; users still log into their primary accounts with passwords (or with 'Sign in with X' which itself uses OAuth). True passwordless approaches use passkeys and FIDO2 instead.
Is OAuth required for SaaS APIs?
Strongly recommended for B2C and partner-facing APIs. Server-to-server APIs may use API keys without OAuth. For Indian solar SaaS partner integrations, OAuth 2.0 is the expected standard.
Run your solar business on QuickEstimate
India's mobile-first solar CRM. Send subsidy-ready proposals on WhatsApp in 60 seconds. Free for 10 proposals a month, no card.
Start free →Sources
- RFC 6749. OAuth 2.0 specification.
- RFC 7636. PKCE for OAuth 2.0.
- OAuth.net documentation.
- Google OAuth 2.0 implementation guide.
- Auth0 OAuth resources.
- OWASP OAuth security guidelines.
- QuickEstimate integration documentation.
Written by QuickEstimate Editorial, QuickEstimate Editorial (Surat).
Last updated: 4 June 2026.