OAuth Integrations allow third-party applications, backend services, and automation tools to securely access Yeeflow APIs using OAuth 2.0 and OpenID Connect.
From the Yeeflow Admin Center, administrators can create OAuth clients, choose the appropriate authorization model, manage client secrets, define scopes and resource boundaries, and review integration activity from one central location.
Before you begin
Before creating an OAuth Integration, make sure that:
You have permission to access the Yeeflow Admin Center.
The third-party application supports OAuth 2.0.
You know whether the integration requires user sign-in, system-to-system authentication, or both.
You have the callback or redirect URI for user authorization scenarios.
You understand which Yeeflow resources the integration needs to access.
Open OAuth Integrations
Open the Admin Center.
In the left navigation, expand Integrations.
Select OAuth integrations.
The OAuth Integrations page displays existing integrations and their current configuration, including:
Name
Application type
Client ID
Status
Scopes
Modified time
Use the search box to locate an existing integration.
Create an OAuth Integration
Click New OAuth integration.
In the dialog, configure the basic information for the integration.
Integration name
Enter a clear name that identifies the connected application or service.
Company / Owner name
Enter the organization, team, or owner responsible for the integration.
Description
Optionally add a description explaining what the integration is used for.
Application type
Choose the authorization model used by the integration.
User Authorization
Use this option when users must sign in and authorize the application to access Yeeflow on their behalf.
Typical scenarios include:
Web applications
Mobile applications
Customer portals
Employee-facing tools
Applications that need user identity information
User Authorization requires one or more trusted Redirect URIs.
System-to-System
Use this option for backend services and automated integrations that do not require user interaction.
Typical scenarios include:
Scheduled data synchronization
Integration middleware
Background services
Automation platforms
Server-to-server API access
Both
Use this option when the same integration needs to support both user-delegated access and system-to-system authentication.
After completing the required fields, click OK.
Yeeflow creates the OAuth Integration and generates a unique Client ID.
Configure basic information
Open an OAuth Integration and select the Basic information tab.
This page contains the main OAuth client configuration.
Integration credentials
Review or edit:
Integration name
Company / Owner name
Description
Client ID
Redirect URIs
Click Edit to update the editable fields.
Client ID
The Client ID is the public identifier of the OAuth Integration.
The external application uses it when requesting authorization or access tokens.
The Client ID is not treated as a secret, but it should still be managed as part of the integration configuration.
Redirect URIs
Redirect URIs are required for User Authorization and Both application types.
After the user completes authentication, Yeeflow sends the authorization response to one of the registered Redirect URIs.
The Redirect URI sent in the authorization request must exactly match a URI registered in the OAuth Integration.
Important:
Register only trusted HTTPS endpoints. Avoid using broad, wildcard, or unverified callback addresses.
OAuth and OpenID Connect endpoints
The lower section of the Basic Information page includes the endpoints required to configure the external application.
OAuth 2.0 authorization endpoint
Used to start the user authorization process.
OAuth 2.0 token endpoint
Used by the application to exchange an authorization code or client credentials for an access token.
OpenID Connect metadata document
Provides the OpenID Connect provider metadata, including supported endpoints and protocol information.
Use the copy button beside each value to copy it into the external application's OAuth configuration.
Monitor integration activity
The OAuth Integration details page includes activity and administration logs.
Call Log
The Call Log records API requests associated with the OAuth client.
Use it to review information such as:
Timestamp
HTTP method
Request path
Response status
Call Logs can help troubleshoot failed requests, validate integration activity, and identify unexpected usage.
Audit Log
The Audit Log records configuration and administrative changes.
Examples include:
Integration created
Basic information updated
Client Secret created
Scopes changed
Integration enabled or disabled
Integration deleted
Use the Audit Log to support security reviews and change tracking.
Manage client secrets
Select the Secret settings tab to create and manage Client Secrets.
A Client Secret is a private credential used by the external application to authenticate itself when requesting tokens.
Create a Client Secret
Open the Secret settings tab.
Click New Client secret.
Enter a Secret name.
Select an expiration period.
Click OK.
Available expiration periods include:
30 days
90 days
180 days
365 days
730 days
Choose an expiration period that matches your organization's credential rotation policy.
Secret name
Use a meaningful name that identifies the purpose or environment.
Store the Client Secret securely
After creation, copy the Client Secret and store it in a secure secret-management system.
Do not store it in:
Client-side application code
Public repositories
Shared documents
Unencrypted configuration files
Important
Treat a Client Secret like a password. Anyone with the Client ID and a valid Client Secret may be able to request tokens within the configured permissions.
Rotate Client Secrets
Create a new Client Secret before the current secret expires, update the external application, verify that authentication succeeds, and then remove or stop using the previous secret.
Using overlapping secrets during rotation can help avoid service interruption.
Configure scopes and permissions
Select the Scopes & Permissions tab.
Scopes define what the connected application is allowed to request or access.
Click Edit to change the selected scopes.
Grant only the permissions required by the integration.
Identity scopes
Identity scopes are mainly used with User Authorization and OpenID Connect.
openid
Verifies the user's identity and enables OpenID Connect authentication.
Select openid when the application needs to sign users in.
profile
Allows access to basic profile information.
Use this scope when the connected application needs details such as the user's display information.
Allows access to the user's email address.
Use this scope only when the email address is required by the application.
For most OpenID Connect sign-in scenarios, the common combination is:
Platform scopes
Platform scopes control access to tenant-level information.
tenant.read
Allows the application to view organization or tenant details.
tenant.write
Allows the application to view, create, update, or delete organization details.
Because write permissions are more powerful, enable tenant.write only when the integration must modify tenant-level information.
Workspace scopes
Workspace scopes control access to workspace information.
workspace.read
Allows the application to view workspace information.
workspace.write
Allows the application to view, create, update, or delete workspace information.
When workspace access is enabled, use the resource scope settings to determine whether the integration can access:
The full tenant
Specific workspaces only
Restricting access to selected workspaces helps prevent the integration from operating outside its approved business area.
Note:
Selecting a workspace resource boundary does not automatically grant access to application records. The relevant Application scope must also be enabled when application data access is required.
Application scopes
Application scopes control access to application records.
app.read
Allows the integration to view application records.
app.write
Allows the integration to view, create, update, or delete application records.
Use app.read for reporting, search, or synchronization scenarios that do not modify records.
Use app.write only when the integration must create or change business data.
Enable or disable an OAuth Integration
The status control appears at the top of the integration details page.
Use it to enable or disable the integration.
When disabled:
New authorization requests should no longer succeed.
The external application cannot continue requesting new tokens through the disabled client.
The configuration remains available for later reactivation.
Disabling an integration is useful when temporarily suspending access without deleting the configuration.
Delete an OAuth Integration
Delete an integration when it is no longer required.
Open the OAuth Integration.
Click Delete.
Confirm the deletion.
Deleting an OAuth Integration permanently removes the client configuration and prevents the associated credentials from being used for future authorization.
Before deleting it, confirm that no active application or service still depends on the integration.
Test an OAuth Integration
After configuration, test the integration from the external application or an OAuth-compatible API client.
For a User Authorization integration, verify that:
The application redirects the user to the Yeeflow authorization endpoint.
The correct Client ID is included.
The requested Redirect URI exactly matches a registered URI.
The requested scopes are enabled.
The user can authenticate and approve access.
The application can exchange the authorization code for a token.
The token can access only the approved resources.
For a System-to-System integration, verify that:
The Client ID and Client Secret are correct.
The token request is sent to the Yeeflow token endpoint.
The requested scopes are enabled.
A valid access token is returned.
API requests are limited to the configured scopes and resource boundaries.
After testing, review the Call Log to confirm that the requests were recorded.
Best practices
To maintain a secure OAuth configuration:
Create a separate OAuth Integration for each external application or environment.
Use User Authorization only when the application must act on behalf of a signed-in user.
Use System-to-System for backend automation without user interaction.
Grant the minimum scopes required.
Restrict workspace access to selected workspaces whenever possible.
Avoid granting write scopes to read-only integrations.
Register only trusted Redirect URIs.
Use short-lived Client Secrets where operationally practical.
Rotate Client Secrets before expiration.
Review Call Logs and Audit Logs regularly.
Disable or delete unused integrations promptly.
OAuth Integrations and App Credentials
OAuth Integrations and App Credentials support different access scenarios.
OAuth Integrations are managed at the tenant level in Admin Center and provide a standardized OAuth 2.0 authorization model for third-party applications and services.
App Credentials are managed inside an individual application and define access to specific application resources.
In scenarios requiring both layers, OAuth can establish the authenticated client and authorized scope, while application-level permissions determine which application resources the integration can use.
Together, they support secure external access without granting broader permissions than the integration requires.