Authentication Auth2.0 - Authorization code

OAuth 2.0 – Authorization Code Grant Type

Purpose:
This is the most secure OAuth flow for server-side applications. It ensures tokens and secrets are kept safe, avoids exposing sensitive data in browser URLs, and supports token refresh for long-term access.

1. Configure Your Fields

Define any extra fields you want to capture along with OAuth authentication.

• Example: API region, environment (sandbox vs production), or account type.

• Keep the number of fields low — OAuth already provides most identity information.

• Tip: If you need optional fields, mark them as not required to improve UX.

2. Copy Your OAuth Redirect URL

The redirect (callback) URL is where the external service sends the authorization code after the user approves access.

• This must exactly match what’s set in the provider’s developer portal — mismatches cause “redirect_uri_mismatch” errors.

• Tip: If your app has multiple environments (dev, staging, prod), register each redirect URL.

3. Enter Application Credentials

Add the Client ID and Client Secret provided by the external service.

• The Client ID is public — it identifies your app.

• The Client Secret is private — treat it like a password and never expose it in frontend code.

• Common pitfall: Mixing up credentials from different environments (e.g., staging vs production).

4. Configure Authorization Endpoint

This is the URL where users log in and consent to share data with your app.

• Example: https://service.com/oauth/authorize

• Usually includes query parameters like:

  • response_type=code

  • client_id

  • redirect_uri

  • scope (requested permissions)

  • state (optional anti-CSRF token)

• Tip: Always use the state parameter for security.

5. Configure Access Token API

The endpoint used to exchange the authorization code for an access token (and optionally a refresh token).

• Requires a secure POST request.

• Typical parameters: grant_type=authorization_code, code, redirect_uri, client_id, client_secret.

• Tip: Handle error responses like invalid_grant gracefully — they often indicate an expired or already used code.

6. Configure Refresh Token API

Allows the system to obtain a new access token without user involvement.

• Keeps the connection alive when tokens expire.

• Tip: Always check if the provider returns a refresh_token in the initial token exchange — not all do.

7. Configure Revoke Token API

Optional but recommended — lets users disconnect securely.

• Revoking tokens prevents further API access.

• Tip: Call this API both when a user manually disconnects and when credentials are invalid.

8. Configure Test (Me) API

A lightweight request to verify token validity.

• Example: /me or /user/profile.

• Helps detect expired or revoked tokens early.

• Tip: Choose an endpoint that’s quick and always available.

9. Add Connection Label

Gives users a friendly name for their saved connection.

• Example: Jane’s Google Drive.

• Tip: Dynamically build it from Test API data (like the user’s name or company).

10. Add URLs to Whitelist

Specifies which domains or endpoints are allowed.

• Protects against malicious or accidental calls to unauthorized destinations.

• Tip: Be strict — only whitelist the API host and necessary subdomains.

11. Add Unique Authentication Identifier

Ensures each connection is linked to a unique user/account in the external system.

• Prevents duplicate connections.

• Tip: Use a value from the Test API like account_id or email.

12. Set Request Parameters

Defines default query or body parameters that should be included in every API call.

• Useful for static requirements like api_version=2.

• Tip: Don’t store sensitive data here — tokens are handled by viaSocket.

Extra Best Practices

• Scope Minimization: Only request the permissions you truly need — this builds user trust.

• Token Security: Store tokens encrypted, never in browser storage.

• Error Transparency: If authorization fails, show the actual error message to help users fix it.

• State Validation: Always verify the state parameter on callback to prevent CSRF attacks.

Use Cases:

• Web applications with server-side components.

• Applications requiring long-lived access.

Security Considerations:

• The authorization code is short-lived and exchanged for a token.

• Client secrets are not exposed to the user.

• Recommended for most applications due to its security features.

OAuth 2.0 Demo

Click through a step-by-step, interactive demo walkthrough of Viasocket, powered by Supademo.

https://app.supademo.com/embed/cm669cr4r00ir1xdhpmrjim0l?embed_v=2