WorkOS Connect
Enable 3rd-party authentication via “Sign in with [Your App],” Identity Delegation, and Machine to Machine tokens.
Successful products need more than authentication — they need to connect customer services, partner applications, and external SaaS tools. Each of these integrations adds complexity:
- How do you manage different types of sessions and token validation across various services?
- How do customers and partners create and manage credentials securely?
- Which technology is right—OAuth, OIDC, bearer tokens, client credentials?
It is critical to build this correctly to avoid security issues and enable a great experience for your users and partners. That’s where WorkOS Connect comes in.
WorkOS Connect is a unified interface that simplifies authentication and authorization across customers, partners, and external SaaS tools.
With minimal integration effort, WorkOS Connect handles session management, token validation, credential provisioning, and more.
How WorkOS Connect helps you reach more customers and partners
WorkOS Connect provides an end-to-end authentication solution for three common product expansion use cases:
- Allowing third-party developers to authenticate with your application (via OAuth 2.0)
- Leveraging one identity layer across all your first-party surfaces (eg. support sites and docs)
- Standardizing customer API access via machine-to-machine tokens
Use case #1 - “Sign in with [Your App]”
Say you’ve built a hot new AI app and you want to enable other developers to build on top of your platform. With WorkOS Connect you can enable these developers to “Sign in with [Your App]” via OAuth 2.0.
When you create a new application for a given partner, a client id and client secret are created that the partner can use in their app to allow users to authenticate into their app with your identity. You have likely seen a similar page from Google or GitHub when signing into 3rd-party apps:
When a user selects “Sign in with Your App” on the developer’s application, they are redirected to your app’s AuthKit sign in page. After successfully authenticating, the user is presented with a consent screen requesting permission to share information with the developer’s app.
.png)
Once the user consents, they’re redirected back to the developer’s application along with an authorization code. The developer’s application exchanges this authorization code for an access token, which it can use to interact with your app’s resources. At this point, the user is signed in into the developer’s application using the same identity they have in your app.
Use case #2 - A single identity for your multiple applications and vendors
Your product experience is likely more than just one application.
For example, you may have a community where users share knowledge with each other. Or a vendor for support services like Zendesk. Or you may even allow users to sign in to your docs to embed personalized information like test credentials. In all of these cases, your users shouldn’t have to manage multiple identities. Although these are separate apps, they should share the same identity layer to behave as one single experience for users.
WorkOS Connect enables your app to use a single identity service across multiple apps. Similar to the third party integrations detailed above, you can configure each app to authenticate users via AuthKit with the same credentials. Because these are 1st-party surfaces, no additional consent screen is displayed. Once authenticated, users are redirected back to the supporting application and immediately signed in. No additional setup or verification needed.
Use case #3 - Machine-To-Machine (M2M) credentials for API access
Providing customers with API access is essential, but it’s often rushed to avoid blocking adoption. WorkOS Connect allows you to provision credentials for customer leveraging the OAuth 2.0 standard client credentials grant. Using OAuth means that there is existing tooling across most programming language for integrating these credentials. This makes it easier to integrate the client credential flow into your own SDKs. B2B apps, however, have unique security requirements—especially around how customers manage API credentials.
For B2B Apps, a common pitfall with managing API access is scoping tokens to individual users, leaving organization admins unable to manage or revoke them. If a token is leaked, admins can’t mitigate the breach without your involvement to track down the token and revoke it.
WorkOS Connect avoids this problem by tying credentials to an organization, giving the admins of the organization direct visibility and control over all provisioned credentials. This gives them the power to respond in real time to a leak and removes the need for escalations and the dreaded manual “API credential” reports - where you have to manually pull a list so your customer’s can review all tokens in their org.
After creating an application and providing the client id and client secret to you customer, the process to use the client is as follows:
- The customer’s application will authenticate first through WorkOS Connect presented via your custom branded auth endpoint
- WorkOS will validate the client id and secret along with any scopes passed in the request
- If validated, WorkOS Connect will return an access token
- The customer can then use that access token in API calls to your API
- From this point on your customer’s app continues to make requests and receive responses from your API until the access token expires.
Access tokens issued by WorkOS Connect are JWTs just like with AuthKit. That means if you are already using AuthKit, then supporting API access with WorkOS Connect is seamless.
Get started
WorkOS Connect enables you to expand your service to more customers, partners, and vendors so they can seamlessly connect via industry standards. To get started, reach out to support@workos.com to enable WorkOS Connect for your account.