The WorkOS API enables adding Enterprise Ready features to your application. This REST API provides programmatic access to AuthKit (user management), Single Sign-On, Directory Sync, and Audit Log resources.

Sign in to see code examples customized with your API keys and data.

https://api.workos.com

WorkOS offers native SDKs in several popular programming languages. Choose one language below to see our API Reference in your application’s language.

You can test the API directly with cURL, or use the Postman collection for convenience.

WorkOS authenticates your API requests using your account’s API keys. API requests made without authentication or using an incorrect key will return a 401 error. Requests using a valid key but with insufficient permissions will return a 403 error. All API requests must be made over HTTPS. Any requests made over plain HTTP will fail.

curl https://api.workos.com/directories \
  --header "Authorization: Bearer sk_example_123456789"

You can view and manage your API keys in the WorkOS Dashboard.

Secure your API Keys

API keys can perform any API request to WorkOS. They should be kept secure and private! Be sure to prevent API keys from being made publicly accessible, such as in client-side code, GitHub, unsecured S3 buckets, and so forth. API keys are prefixed with sk_.

In Staging

Your Staging Environment comes with an API key already generated for you. Staging API keys may be viewed as often as they are needed and will appear inline throughout our documentation in code examples if you are logged in to your WorkOS account. API requests will be scoped to the provided key’s Environment.

In Production

Once you unlock Production access you will need to generate an API Key for it. Production API keys may only be viewed once and will need to be saved in a secure location upon creation of them.

WorkOS uses standard HTTP response codes to indicate the success or failure of your API requests.

200

Successful request.

400

The request was not acceptable. Check that the parameters were correct.

401

The API key used was invalid.

403

The API key used did not have the correct permissions.

404

The resource was not found.

422

Validation failed for the request. Check that the parameters were correct.

429

Too many requests. Refer to the Rate Limits section.

5xx

Indicates an error with WorkOS servers.

Many top-level resources have support for bulk fetches via list API methods. For instance, you can list connections, list directory users, and list directory groups. These list API methods share a common structure, taking at least these four parameters: limit, order, after, and before.

WorkOS utilizes pagination via the after and before parameters. Both parameters take an existing object ID value and return objects in either descending or ascending order by creation time.

curl https://api.workos.com/connections?limit=100 \
  --header "Authorization: Bearer sk_example_123456789"

WorkOS APIs are rate limited to ensure that they are fast for everyone. If you find yourself getting 429 errors, double check your integration to make sure you aren’t making unnecessary requests.

General

This rate limits applies to all environments, staging and production. Exceptions to the general rate limit are listed below.

Single Sign-On

Directory Sync

Organizations

AuthKit

Rate limiting for AuthKit APIs are enforced on an account basis.

Hosted AuthKit

Events represent activity that has occurred within WorkOS or within third-party identity and directory providers. They are used to keep your app in sync with WorkOS data. For more details on consuming events in your app, check out the data syncing guide.

Refer to the Events page for a full list of events that WorkOS emits.

Get a list of all of events up to 30 days old.

curl --request GET --url "https://api.workos.com/events?events=dsync.user.created,dsync.user.updated,dsync.user.deleted" \
  --header "Authorization: Bearer sk_example_123456789"

An Organization is a top-level resource in WorkOS. Each Connection, Directory, and Audit Trail Event belongs to an Organization. An Organization will usually represent one of your customers. There is no limit to the number of organizations you can create in WorkOS.

{
  "object": "organization",
  "id": "org_01EHZNVPK3SFK441A1RGBFSHRT",
  "name": "Foo Corp",
  "created_at": "2021-06-25T19:07:33.155Z",
  "updated_at": "2021-06-25T19:07:33.155Z",
  "domains": [
    {
      "object": "organization_domain",
      "id": "org_domain_01EHZNVPK2QXHMVWCEDQEKY69A",
      "organization_id": "org_01HE8GSH8FQPASKSY27THRKRBP",
      "domain": "foo-corp.com",
      "state": "verified",
      "verification_strategy": "dns",
      "verification_token": "m5Oztg3jdK4NJLgs8uIlIprMw"
    }
  ],
  "stripe_customer_id": "cus_R9qWAGMQ6nGE7V",
  "external_id": "2fe01467-f7ea-4dd2-8b79-c2b4f56d0191",
  "metadata": {
    "tier": "diamond"
  }
}

Get the details of an existing organization.

curl https://api.workos.com/organizations/org_01EHZNVPK3SFK441A1RGBFSHRT \
  --header "Authorization: Bearer sk_example_123456789"

Get the details of an existing organization by an external identifier.

curl https://api.workos.com/organizations/external_id/2fe01467-f7ea-4dd2-8b79-c2b4f56d0191 \
  --header "Authorization: Bearer sk_example_123456789"

Get a list of all of your existing organizations matching the criteria specified.

curl https://api.workos.com/organizations?domains=foo-corp.com \
  --header "Authorization: Bearer sk_example_123456789"

Creates a new organization in the current environment.

You can include one or more domains to associate with the organization, but you should verify the ownership of every domain before setting its state to verified.

curl --request POST \
  --url https://api.workos.com/organizations \
  --header "Authorization: Bearer sk_example_123456789" \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "name": "Foo Corp",
    "domain_data": [
      {
        "domain": "foo-corp.com",
        "state": "pending"
      }
    ],
    "external_id": "2fe01467-f7ea-4dd2-8b79-c2b4f56d0191",
    "metadata": {
      "tier": "diamond"
    }
  }
BODY

Updates an organization in the current environment.

You can include one or more domains to associate with the organization, but you should verify the ownership of every domain before setting its state to verified.

curl --request PUT \
  --url https://api.workos.com/organizations/org_01EHZNVPK3SFK441A1RGBFSHRT \
  --header "Authorization: Bearer sk_example_123456789" \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "name": "Foo Corp",
    "domain_data": [
      {
        "domain": "foo-corp.com",
        "state": "verified"
      }
    ],
    "stripe_customer_id": "cus_R9qWAGMQ6nGE7V",
    "external_id": "2fe01467-f7ea-4dd2-8b79-c2b4f56d0191",
    "metadata": {
      "tier": "diamond"
    }
  }
BODY

Permanently deletes an organization in the current environment. It cannot be undone.

curl --request DELETE \
  --url https://api.workos.com/organizations/org_01EHZNVPK3SFK441A1RGBFSHRT \
  --header "Authorization: Bearer sk_example_123456789"

An Organization Domain (also known as a User Email Domain) represents an Organization’s domain.

These domains restrict which email addresses are able to sign in through SAML Connections when allow profiles outside organization is false. This is the default behavior for Organizations. See SSO frequently asked questions for more details on this behavior.

Organization domains can be verified manually (through the API or the Dashboard), or through a self-serve flow through the Admin Portal. The organization that defines this domain policy exerts authentication policy control over that domain across your application. For this reason, it is important to verify ownership of manually added domains. Additionally, WorkOS does not allow addition of common consumer domains, like gmail.com.

{
  "object": "organization_domain",
  "id": "org_domain_01EHZNVPK2QXHMVWCEDQEKY69A",
  "organization_id": "org_01HE8GSH8FQPASKSY27THRKRBP",
  "domain": "foo-corp.com",
  "state": "verified",
  "verification_strategy": "dns",
  "verification_token": "m5Oztg3jdK4NJLgs8uIlIprMw"
}

A role is an access control resource that can be assigned to organization memberships, directory users, and SSO profiles.

{
  "object": "role",
  "id": "role_01EHZNVPK3SFK441A1RGBFSHRT",
  "name": "Member",
  "slug": "member",
  "description": "Access to basic resources",
  "permissions": ["posts:read", "posts:write"],
  "type": "EnvironmentRole",
  "created_at": "2021-06-25T19:07:33.155Z",
  "updated_at": "2021-06-25T19:07:33.155Z"
}

Get a list of all roles for the provided organization in priority order. Includes all environment and organization roles.

curl https://api.workos.com/organizations/org_01EHZNVPK3SFK441A1RGBFSHRT/roles \
  --header "Authorization: Bearer sk_example_123456789"

AuthKit is a user management platform that provides a set of user authentication and organization security features designed to provide a fast, scalable integration while handling all of the user management complexity that comes with advanced B2B customer needs.

To automatically respond to AuthKit activities, like authentication and changes related to the users, use the corresponding events.

Represents a user identity in your application. A user can sign up in your application directly with a method like password, or they can be JIT-provisioned through an organization’s SSO connection.

Users may belong to organizations as members.

See the events reference documentation for the user events.

{
  "object": "user",
  "id": "user_01E4ZCR3C56J083X43JQXF3JK5",
  "email": "marcelina.davis@example.com",
  "first_name": "Marcelina",
  "last_name": "Davis",
  "email_verified": true,
  "profile_picture_url": "https://workoscdn.com/images/v1/123abc",
  "last_sign_in_at": "2021-06-25T19:07:33.155Z",
  "external_id": "f1ffa2b2-c20b-4d39-be5c-212726e11222",
  "metadata": {
    "language": "en"
  },
  "created_at": "2021-06-25T19:07:33.155Z",
  "updated_at": "2021-06-25T19:07:33.155Z"
}

Get the details of an existing user.

curl https://api.workos.com/user_management/users/user_01E4ZCR3C56J083X43JQXF3JK5 \
  --header "Authorization: Bearer sk_example_123456789"

Get the details of an existing user by an external identifier.

curl https://api.workos.com/user_management/users/external_id/f1ffa2b2-c20b-4d39-be5c-212726e11222 \
  --header "Authorization: Bearer sk_example_123456789"

Get a list of all of your existing users matching the criteria specified.

curl https://api.workos.com/user_management/users \
  --header "Authorization: Bearer sk_example_123456789"

Create a new user in the current environment.

curl --request POST \
  --url https://api.workos.com/user_management/users \
  --header "Authorization: Bearer sk_example_123456789" \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "email": "marcelina@example.com",
    "password": "i8uv6g34kd490s",
    "first_name": "Marcelina",
    "last_name": "Davis",
    "email_verified": false
  }
BODY

Updates properties of a user. The omitted properties will be left unchanged.

curl --request PUT \
  --url https://api.workos.com/user_management/users/user_01EHQ7ZGZ2CZVQJGZ5ZJZ1ZJGZ \
  --header "Authorization: Bearer sk_example_123456789" \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "first_name": "Marcelina",
    "last_name": "Davis",
    "email_verified": true,
    "external_id": "2fe01467-f7ea-4dd2-8b79-c2b4f56d0191",
    "metadata": {
      "language": "en"
    }
  }
BODY

Permanently deletes a user in the current environment. It cannot be undone.

curl --request DELETE \
  --url https://api.workos.com/user_management/users/user_01F3GZ5ZGZBZVQGZVHJFVXZJGZ \
  --header "Authorization: Bearer sk_example_123456789"

Represents User identities obtained from external identity providers.

When a user authenticates using an external provider like Google OAuth, information from that provider will be made available as one of the user’s Identities. You can read more about the process in our identity linking guide.

{
  "idp_id": "4F42ABDE-1E44-4B66-824A-5F733C037A6D",
  "type": "OAuth",
  "provider": "MicrosoftOAuth"
}

Get a list of identities associated with the user. A user can have multiple associated identities after going through identity linking. Currently only OAuth identities are supported. More provider types may be added in the future.

curl https://api.workos.com/user_management/users/user_01E4ZCR3C56J083X43JQXF3JK5/identities \
  --header "Authorization: Bearer sk_example_123456789"

Authenticate a user with a specified authentication method.

Generates an OAuth 2.0 authorization URL to authenticate a user with AuthKit or SSO.

curl https://api.workos.com/user_management/authorize -G \
  -d response_type=code \
  -d client_id=client_123456789 \
  -d redirect_uri=https://your-app.com/callback \
  -d state=dj1kUXc0dzlXZ1hjUQ== \
  -d connection_id=conn_01E4ZCR3C56J083X43JQXF3JK5

If you are using AuthKit, set the provider parameter to "authkit", which will generate an authorization URL for your AuthKit domain. AuthKit will take care of detecting the user’s authentication method, such as identifying whether they use Email + Password or Single Sign-On,and direct them to the corresponding login flow.

Otherwise, to generate an authorization URL for a WorkOS SSO connection, you’ll have to specify the user’s connection, organization, or OAuth provider as a parameter. These connection selectors are mutually exclusive, and exactly one must be provided. The generated URL automatically directs the user to their identity provider. Once the user authenticates with their identity provider, WorkOS then issues a redirect to your redirect URI to complete the sign-in flow.

Redirect URI

In the OAuth 2.0 protocol, a redirect URI is the location that the user is redirected to once they have successfully authenticated with their identity provider.

When redirecting the user, WorkOS will generate an authorization code and pass it to your redirect URI as a code query parameter, your app will use this code to authenticate the user. Additionally, WorkOS can pass a state parameter back to your application that you may use to encode arbitrary information to restore your application state between the redirects.

https://your-app.com/callback?code=01E2RJ4C05B52KKZ8FSRDAP23J&state=dj1kUXc0dzlXZ1hjUQ==

You can use state to encode parameters like originating URL and query parameters. This is useful in a flow where unauthenticated users are automatically redirected to a login page. After successful sign in, users will be routed to your redirect URI callback route. From there you can extract the originating URL from state and redirect the user to their intended destination.

You’ll need to configure the allowed redirect URIs for your application via the Redirects page in the dashboard. Without a valid redirect URI, your users will be unable to sign in. Make sure that the redirect URI you use as a parameter to get the authorization URL matches one of the redirect URIs you have configured in the dashboard.

Redirect URIs follow stricter requirements in production environments:

• HTTPS protocol is required in production environments
• HTTP and localhost are allowed in staging environments
• The sole exception is the use of http://127.0.0.1 in production environments to support native clients.

Wildcards

WorkOS supports using wildcard characters in Redirect URIs. The * symbol can be used as a wildcard for subdomains; however, it must be used in accordance with the following rules in order to properly function.

• The wildcard must be located in a subdomain within the hostname component. For example, http://*.com will not work.
• The wildcard must be located in the subdomain which is furthest from the root domain. For example, https://sub.*.example.com will not work.
• The URL must not contain more than one wildcard. For example, https://*.*.example.com will not work.
• A wildcard character may be prefixed and/or suffixed with additional valid hostname characters. For example, https://prefix-*-suffix.example.com will work.
• A URL with a valid wildcard will not match a URL more than one subdomain level in place of the wildcard. For example, https://*.example.com will not work with https://sub1.sub2.example.com.
• In production environments, wildcards cannot be used with public suffix domains. For example, https://*.ngrok-free.app will not work.
• The wildcard will match a sequence of letters (A through Z, and a through z ); digits (0 through 9), hyphens (-), and underscores (_). For example, https://user:secret@foo.example.com will not work with https://*.example.com.
• A URL with a wildcard cannot be set as the default redirect URI.

PKCE

The Proof Key for Code Exchange (PKCE) flow is an extension to the OAuth 2.0 Authorization Code flow. It enables public clients, like native apps or single-page apps, to perform the authorization code flow securely. If you are developing a client that makes API calls in public, you’ll need to use this flow.

In this flow, your client generates a code verifier which is a high-entropy cryptographic random string. A code challenge is derived by hashing the code verifier. Instead of using a client secret, provide the code challenge when getting the authorization URL and the code verifier when authenticating a User.

Error codes

If there is an issue generating an authorization URL, the API will return the original redirect URI with error and error_description query parameters. If provided, the state value will also be included.

https://your-app.com/callback?error=organization_invalid&error_description=No%20connection%20associated%20with%20organization&state=123456789

Possible error codes and the corresponding descriptions are listed below.

Authenticates a user using AuthKit, OAuth or an organization’s SSO connection.

AuthKit handles all authentication methods, however it is conceptually similar to a social login experience. Like OAuth and SSO, AuthKit returns you a code that you can exchange for an authenticated user. See Integrating with AuthKit.

curl --request POST \
  --url https://api.workos.com/user_management/authenticate \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "client_id": "client_123456789",
    "client_secret": "sk_example_123456789",
    "grant_type": "authorization_code",
    "code": "01E2RJ4C05B52KKZ8FSRDAP23J",
    "ip_address": "192.0.2.1",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
  }
BODY

Authenticates a user with email and password.

curl --request POST \
  --url https://api.workos.com/user_management/authenticate \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "client_id": "client_123456789",
    "client_secret": "sk_example_123456789",
    "grant_type": "password",
    "email": "marcelina@example.com",
    "password": "i8uv6g34kd490s",
    "ip_address": "192.0.2.1",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
  }
BODY

Authenticates a user by verifying the Magic Auth code sent to the user’s email.

curl --request POST \
  --url https://api.workos.com/user_management/authenticate \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "client_id": "client_123456789",
    "client_secret": "sk_example_123456789",
    "grant_type": "urn:workos:oauth:grant-type:magic-auth:code",
    "code": "123456",
    "email": "marcelina.davis@example.com",
    "ip_address": "192.0.2.1",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
  }
BODY

Use this endpoint to exchange a refresh token for a new access token. Refresh tokens may be rotated after use, so a replacement refresh token is also provided.

curl --request POST \
  --url https://api.workos.com/user_management/authenticate \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "client_id": "client_123456789",
    "client_secret": "sk_test_123",
    "grant_type": "refresh_token",
    "refresh_token": "Xw0NsCVXMBf7svAoIoKBmkpEK",
    "ip_address": "192.0.2.1",
    "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0"
  }
BODY

Authenticates a user with an unverified email and verifies their email address.

A user with an unverified email address won’t be able to authenticate right away. When they attempt to authenticate with their credentials, the API will return an email verification required error that contains a pending authentication token.

If the email setting for email verification is enabled, WorkOS will automatically send a one-time email verification code to the user’s email address. If the email setting is not enabled, retrieve the email verification code to send the email yourself. Use the pending authentication token from the error and the one-time code the user received to authenticate them and to complete the email verification process.

curl --request POST \
  --url https://api.workos.com/user_management/authenticate \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "client_id": "client_123456789",
    "client_secret": "sk_example_123456789",
    "grant_type": "urn:workos:oauth:grant-type:email-verification:code",
    "code": "123456",
    "pending_authentication_token": "ql1AJgNoLN1tb9llaQ8jyC2dn",
    "ip_address": "192.0.2.1",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
  }
BODY

Authenticates a user enrolled into MFA using time-based one-time password (TOTP).

Users enrolled into MFA are required to enter a TOTP each time they sign in. When they attempt to authenticate with their credentials, the API will return an MFA challenge error that contains a pending authentication token.

To continue with the authentication flow, challenge one of the factors returned by the MFA challenge error response and present a UI to the user to enter the TOTP code. Then, authenticate the user with the TOTP code, the challenge from the factor, and the pending authentication token from the MFA challenge error.

MFA can be enabled via the Authentication page in the WorkOS dashboard.

curl --request POST \
  --url https://api.workos.com/user_management/authenticate \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "client_id": "client_123456789",
    "client_secret": "sk_example_123456789",
    "grant_type": "urn:workos:oauth:grant-type:mfa-totp",
    "code": "123456",
    "pending_authentication_token": "ql1AJgNoLN1tb9llaQ8jyC2dn",
    "authenticationChallengeId": "auth_challenge_01FVYZWQTZQ5VB6BC5MPG2EYC5",
    "ip_address": "192.0.2.1",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
  }
BODY

Authenticates a user into an organization they are a member of.

When a user who is a member of multiple organizations attempts to authenticate with their credentials, the API will return an organization selection error that contains a pending authentication token. To continue with the authentication flow, your application should display the list of organizations for the user to choose.

Use the pending authentication token from the error and the organization the user selected in your UI to complete the authentication.

curl --request POST \
  --url https://api.workos.com/user_management/authenticate \
  --header "Content-Type: application/json" \
  -d @- <<BODY
  {
    "client_id": "client_123456789",
    "client_secret": "sk_example_123456789",
    "grant_type": "urn:workos:oauth:grant-type:organization-selection",
    "pending_authentication_token": "ql1AJgNoLN1tb9llaQ8jyC2dn",
    "organization_id": "org_01H93Z2SYX1D3NJ536M94T8SHP",
    "ip_address": "192.0.2.1",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
  }
BODY

Authenticates a user using an AuthKit session cookie. This method does not make a network call, but simply unseals an existing session cookie and decodes the JWT claims from the access token.

import {
  AuthenticateWithSessionCookieFailureReason,
  WorkOS,
} from '@workos-inc/node';

const workos = new WorkOS('sk_example_123456789', {
  // clientId is required to be passed in to use the authenticateWithSessionCookie method
  clientId: 'client_123456789',
});

const { authenticated, ...restOfAuthenticationResponse } =
  await workos.userManagement.authenticateWithSessionCookie({
    sessionData: 'sealed_session_cookie_data',
    cookiePassword: 'password_previously_used_to_seal_session_cookie',
  });

if (authenticated) {
  // User is authenticated and session data can be utilized
  const { sessionId, organizationId, role, permissions } =
    restOfAuthenticationResponse;
} else {
  const { reason } = restOfAuthenticationResponse;

  // Can use AuthenticateWithSessionCookieFailureReason to handle failure reasons
  if (
    reason ===
    AuthenticateWithSessionCookieFailureReason.NO_SESSION_COOKIE_PROVIDED
  ) {
    // Redirect the user to the login page
  }
}

Unseals the provided session data from a user’s session cookie, authenticates with the existing refresh token, and returns the sealed data for the refreshed session.

import {
  RefreshAndSealSessionDataFailureReason,
  WorkOS,
} from '@workos-inc/node';

const workos = new WorkOS('sk_example_123456789', {
  // clientId is required to be passed in to use the refreshAndSealSessionData method
  clientId: 'client_123456789',
});

const { authenticated, ...restOfRefreshResponse } =
  await workos.userManagement.refreshAndSealSessionData({
    sessionData: 'sealed_session_cookie_data',
    cookiePassword: 'password_previously_used_to_seal_session_cookie',
  });

if (authenticated) {
  const { sealedSession } = restOfRefreshResponse;

  // Set the sealed session in a cookie
} else {
  const { reason } = restOfRefreshResponse;

  // Can use RefreshAndSealSessionDataFailureReason to handle failure reasons
  if (
    reason === RefreshAndSealSessionDataFailureReason.NO_SESSION_COOKIE_PROVIDED
  ) {
    // Redirect the user to the login page
  }
}

This hosts the public key that is used for verifying access tokens.

curl https://api.workos.com/sso/jwks/client_123456789

The access token that is returned in successful authentication responses is a JWT that can be used to verify that a user has an active session. The JWT is signed by a JWKS which can be retrieved from the WorkOS API.

{
  "iss": "https://api.workos.com",
  "sub": "user_01HBEQKA6K4QJAS93VPE39W1JT",
  "act": {
    "sub": "admin@foocorp.com"
  },
  "org_id": "org_01HRDMC6CM357W30QMHMQ96Q0S",
  "role": "member",
  "permissions": ["posts:read", "posts:write"],
  "entitlements": ["audit-logs"],
  "sid": "session_01HQSXZGF8FHF7A9ZZFCW4387R",
  "jti": "01HQSXZXPPFPKMDD32RKTFY6PV",
  "exp": 1709193857,
  "iat": 1709193557
}

The refresh token can be used to obtain a new access token using the authenticate with refresh token endpoint. Refresh tokens may only be used once. Refreshes will succeed as long as the user’s session is still active.

After authenticating and storing the encrypted session as a cookie, retrieving and decrypting the session is made easy via the session helper methods.

Load the session by providing the sealed session and the cookie password.

import { WorkOS } from '@workos-inc/node';

const workos = new WorkOS('sk_example_123456789', {
  clientId: 'client_123456789',
});

const session = await workos.userManagement.loadSealedSession({
  sessionData: 'sealed_session_cookie_data',
  cookiePassword: 'password_previously_used_to_seal_session_cookie',
});

Unseals the session data and checks if the session is still valid.

import { WorkOS } from '@workos-inc/node';

const workos = new WorkOS('sk_example_123456789', {
  clientId: 'client_123456789',
});

const session = await workos.userManagement.loadSealedSession({
  sessionData: 'sealed_session_cookie_data',
  cookiePassword: 'password_previously_used_to_seal_session_cookie',
});

const authResponse = await session.authenticate();

if (authResponse.authenticated) {
  // User is authenticated and session data can be used
  const { sessionId, organizationId, role, permissions, user } = authResponse;
} else {
  if (authResponse.reason === 'no_session_cookie_provided') {
    // Redirect the user to the login page
  }
}