Authentication Auth2.0 - Authorization code

The most secure OAuth flow for server-side applications.

• Tokens and secrets stay secure

• No sensitive data in browser URLs

• Supports refresh tokens for long-term access

Purpose: Only add fields if truly necessary.

When to Add Extra Fields

Add fields only if OAuth does NOT already provide that data.

Examples

• Region → US / EU

• Environment → Sandbox / Production

Rules

• Keep fields minimal

• All extra fields must be NOT required

• Do NOT add user identity fields (OAuth provides this)

This is the callback URL used after user approval.

The callback URL where the external service will send the access token directly in the URL has (#access_token=…).

Must match the redirect URL registered in the provider’s developer portal.

Tip: Since tokens appear in the browser, make sure the redirect URL is secure (HTTPS).

Get these from the app’s developer dashboard.

Rules

• Never expose client secret

• Use correct environment (Production vs Sandbox)

This is where users log in and approve access.

• Authorization URL
  Enter the Authorization Endpoint from your provider’s docs, e.g.:

  <https://api.provider.com/oauth/authorize>
  This is where the user is sent to log in and approve access.
  You can get the authorization url from the application doc.
  Usually includes params:

  • response_type = code

  • client_id

  • redirect_uri

  • scope

  • state (mandatory)

    Scopes
    Specify what your plugin wants access to - e.g.:

    Read_profile   write_data
    ViaSocket lets you choose whether scopes are joined with:

    • Spaces, or

    • Commas

    Security Tip : Always use state

After approval, viaSocket receives an authorization code.

This step defines how to exchange it for:

• access_token

• refresh_token (optional)

In the application documentation, you need to find the Access Token API and use that API in the access token configuration.

This API usually requires the following fields:

Typical Request Fields

Access tokens expire after a certain time. Refresh tokens are used to generate new access tokens automatically without requiring the user to authorize again.

In the application documentation, find the Refresh Token API and configure it in the same way as the access token step.
viaSocket process:

• Sends a POST request to the refresh token endpoint

• Uses grant_type = refresh_token

• Sends the stored refresh_token

• Receives a new access_token (and sometimes a new refresh_token)

Ensures clean disconnection.

When user disconnects:

• Call provider’s revoke endpoint

• Send active token

• Provider invalidates it

Result: Connection is fully terminated.

Example: https://service.com/oauth/revoke.

From the app documentation, find a GET API that does not require any user input and use it for testing. Some apps provide a dedicated test or “/me” API, which is ideal for this purpose.

Make an authenticated GET request:

• Endpoint examples:

• /me

• /user

• /profile

Header:

Authorization: Bearer <api_key>

If the app does not provide any GET API, you can use a POST API and pass dummy values.

For example, if an API requires a website URL, you can send:
https://viasocket.com/

Success means:

• Token is valid

• Scopes approved

• Header format correct

Shows a human-friendly connection name.

Good Examples

• John Doe

• jane@company.com

• Team Alpha Workspace

Map from Test API response:

“authData.testcode.profile.real_name”

Optional: Mask if sensitive.

Security Step:

You tell viaSocket which domains are allowed.

Example:
https://api.example.com/v1/users

Whitelist:
example.com

Prevents duplicate connections for the same account.

Choose a unique field from the Test or Token response, such as:

• user_id

• workspace_id

• api_app_id

Map it like:

authData.testcode.profile.api_app_id

Why this matters:

• Stops users from connecting the same account multiple times

• Updates existing connections instead of creating duplicates

• Keeps token management clean

Not sure which field to use? You can leave this blank.

Define how authenticated API requests are built.

Headers:

funciton returnApiKey() {

return Bearer ${context.authData?.Api_key};

}

return returnApiKey();

Ensures:

• Latest access token always used

• Works after refresh automatically

With the help of these steps, you don’t need to create the connection again for any action or trigger, and you don’t have to enter or pass the API key repeatedly in each API request.

• 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.