WorkOS, gotowe SSO i SCIM dla klientów firmowych

WorkOS, gotowe SSO i SCIM dla klientów firmowych

WorkOS to zestaw API do funkcji, których dział IT dużego klienta żąda przed podpisaniem umowy: logowania jednokrotnego przez SAML i OIDC, synchronizacji katalogu użytkowników przez SCIM oraz dzienników zdarzeń audytowych. Rozlicza się inaczej niż reszta rynku uwierzytelniania, bo za połączenie z dostawcą tożsamości, a nie za aktywnego użytkownika, i ta jedna różnica decyduje o całym rachunku.

AuthKit i surowe API to dwa różne produkty

Największe nieporozumienie wokół WorkOS bierze się z tego, że pod jedną nazwą sprzedawane są dwie rzeczy o różnym przeznaczeniu i różnym modelu rozliczenia. Dokumentacja SSO otwiera się dosłownie od wyboru jednej z dwóch ścieżek integracji i nie ma tam sugestii, że któraś jest domyślna.

Pierwsza ścieżka to AuthKit. To kompletna warstwa uwierzytelniania z hostowanym interfejsem logowania, obsługą hasła, kodów jednorazowych wysyłanych mailem, kluczy dostępu, uwierzytelniania dwuskładnikowego i ról. W kodzie żyje pod przestrzenią workos.userManagement, a w cenniku pod pozycją User Management. Jeśli budujesz produkt od zera, AuthKit stoi dokładnie w tym samym miejscu, co Clerk albo Kinde, i porównywać go trzeba z nimi.

Druga ścieżka to surowe API Enterprise SSO. Dokumentacja opisuje je jako warstwę pośredniczącą i zaznacza wprost, że ta usługa celowo nie zajmuje się bazą użytkowników Twojej aplikacji. Dostajesz adres autoryzacji, po powrocie profil z danymi z dostawcy tożsamości i na tym kończy się jej rola. Sesję, tabelę kont, przypisanie do organizacji i wszystko dalej piszesz sam. W kodzie to przestrzeń workos.sso, w cenniku pozycja Enterprise SSO rozliczana za połączenie.

Do tego dochodzą produkty, których używa się niezależnie od wybranej ścieżki: Directory Sync, czyli SCIM, Audit Logs, Admin Portal, w którym administrator klienta konfiguruje swojego dostawcę tożsamości bez Twojego udziału, oraz Radar do wykrywania nadużyć. Każdy z nich ma osobną pozycję na rachunku.

Praktyczna konsekwencja jest taka, że aplikacja korzystająca z AuthKit i jednocześnie z Directory Sync płaci dwa rodzaje opłat naraz: za aktywnych użytkowników i za połączenia katalogowe. Pomieszanie obu przestrzeni w kodzie kończy się natomiast tym, że masz dwa niepowiązane pojęcia użytkownika: User z User Management i Profile z SSO, o zupełnie innym zestawie pól.

Wersja, licencja i stan projektu

Klient dla Node nazywa się @workos-inc/node i ma wersję 10.10.0 opublikowaną 13 sierpnia 2026 roku. Odpowiadające jej wydanie v10.10.0 w repozytorium workos/workos-node nosi tę samą datę. Repozytorium odpowiada kodem 200 i nie jest zarchiwizowane.

Licencję sprawdziłem z trzech niezależnych źródeł i tym razem wypada wzorowo. Plik LICENSE w gałęzi głównej repozytorium zawiera tekst MIT z notą prawną z 2021 roku. Pole license w rejestrze npm ma wartość MIT. Opublikowana paczka rozpakowana z archiwum ma dwadzieścia pięć plików, w tym package/LICENSE z tym samym tekstem MIT oraz osiem realnych plików JavaScript z kodem w wariantach CommonJS, ESM i osobnym wejściu dla środowiska Worker. Nie jest to atrapa nazwy ani metapakiet bez zawartości.

Jedna rozbieżność jest po stronie ekosystemu Pythona i ma znaczenie tylko dla automatów sprawdzających zgodność licencyjną. Pakiet workos na PyPI w wersji 10.2.0 z 11 sierpnia 2026 roku deklaruje w metadanych License-Expression: MIT, a repozytorium workos/workos-python ma plik LICENSE z tekstem MIT i notą z 2024 roku. Natomiast samo koło instalacyjne zawiera w katalogu dist-info wyłącznie pliki WHEEL, METADATA i RECORD, bez żadnego pliku licencyjnego. Kod jest, siedemset osiemdziesiąt trzy pliki źródłowe, ale skaner czytający zawartość paczki zamiast metadanych nie znajdzie tam tekstu licencji.

Pułapka nazewnicza: pakiet npm o gołej nazwie workos w wersji 0.21.1 nie jest biblioteką kliencką, tylko narzędziem wiersza poleceń z repozytorium workos/cli. Instalacja pod tą nazwą da coś zupełnie innego niż SDK.

Rytm wydań jest gęsty i nierówny. Wersje 10.4.0 z 18 czerwca, 10.4.1 z 23 czerwca, 10.5.0 z 24 czerwca oraz 10.6.0 i 10.7.0 z 25 czerwca 2026 roku wyszły w ciągu tygodnia, po czym nastąpiła przerwa do 10.8.0 z 17 lipca, 10.9.0 z 30 lipca i 10.10.0 z 13 sierpnia. Warstwa dla Next.js, czyli @workos-inc/authkit-nextjs, ma wersję 4.3.1 z 30 lipca 2026 roku, również na licencji MIT, z plikiem licencyjnym w paczce.

Dwa wymagania techniczne, które łatwo przeoczyć. @workos-inc/node deklaruje engines.node na >=22.11.0, więc na starszym Node instalacja zgłosi ostrzeżenie albo się wyłoży, zależnie od ustawień menedżera pakietów. @workos-inc/authkit-nextjs deklaruje zależności równorzędne na next w zakresie ^13.5.9 || ^14.2.26 || ^15.2.3 || ^16, na react w zakresie ^18.0 || ^19.0.0 i na @workos-inc/node w zakresie ^9.0.0 || ^10.0.0. Węższe zakresy przy Next 13 i 14 to skutek łatek bezpieczeństwa, a nie kaprys.

Rzecz najważniejsza dla oceny ryzyka: licencja MIT dotyczy bibliotek klienckich, a nie usługi. Serwer WorkOS jest zamknięty i hostowany wyłącznie przez dostawcę. Nie ma wariantu do uruchomienia u siebie, nie ma wglądu w kod przetwarzający asercje SAML i nie ma ścieżki wyjścia innej niż przepisanie integracji.

AuthKit w Next.js od zera

Konfiguracja AuthKit w aplikacji Next opiera się na czterech zmiennych środowiskowych, które biblioteka traktuje jako obowiązkowe, oraz na kilku opcjonalnych sterujących ciasteczkiem sesji.

# obowiązkowe
WORKOS_API_KEY=sk_test_xxxxxxxx
WORKOS_CLIENT_ID=client_xxxxxxxx
WORKOS_COOKIE_PASSWORD=co_najmniej_32_znaki_losowego_ciagu
WORKOS_REDIRECT_URI=http://localhost:3000/callback

# opcjonalne, sterujace ciasteczkiem sesji
WORKOS_COOKIE_NAME=wos-session
WORKOS_COOKIE_MAX_AGE=34560000
WORKOS_COOKIE_SAMESITE=lax
WORKOS_COOKIE_DOMAIN=.example.com

Instalacja i pierwsze podłączenie wyglądają tak.

npm install @workos-inc/node@10.10.0 @workos-inc/authkit-nextjs@4.3.1
node --version   # musi byc co najmniej 22.11.0

Pośrednik przechwytuje żądania, odświeża token dostępu przed wygaśnięciem i przekierowuje niezalogowanych, jeśli włączysz middlewareAuth. Pole unauthenticatedPaths jest w tym obiekcie wymagane razem z enabled.

// middleware.ts
import { authkitMiddleware } from '@workos-inc/authkit-nextjs'

export default authkitMiddleware({
  middlewareAuth: {
    enabled: true,
    unauthenticatedPaths: ['/', '/cennik', '/logowanie']
  },
  redirectUri: process.env.WORKOS_REDIRECT_URI,
  refreshBufferSeconds: 60,
  debug: false
})

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)']
}

Trasa powrotna po zalogowaniu sprowadza się do jednej funkcji. Opcja returnPathname mówi, dokąd odesłać użytkownika, a onSuccess daje moment na zapis własnego rekordu w bazie.

// app/callback/route.ts
import { handleAuth } from '@workos-inc/authkit-nextjs'

export const GET = handleAuth({
  returnPathname: '/panel',
  onSuccess: async ({ user, organizationId, accessToken }) => {
    await zapiszProfilLokalnie({
      workosUserId: user.id,
      email: user.email,
      organizationId
    })
  }
})

W komponentach serwerowych sesję czyta się przez withAuth. Wywołanie z ensureSignedIn: true zwraca UserInfo i przekierowuje, gdy sesji nie ma. Wywołanie bez argumentu zwraca UserInfo albo NoUserInfo z polem user ustawionym na null, więc typ trzeba zawęzić samodzielnie.

// app/panel/page.tsx
import { withAuth, signOut } from '@workos-inc/authkit-nextjs'

export default async function Panel() {
  const { user, organizationId, role, permissions, sessionId } = await withAuth({
    ensureSignedIn: true
  })

  const mozeZapraszac = permissions?.includes('members:invite') ?? false

  return (
    <main>
      <h1>{user.email}</h1>
      <p>Organizacja: {organizationId ?? 'brak'}</p>
      <p>Rola: {role ?? 'brak'}</p>
      <p>Sesja: {sessionId}</p>
      {mozeZapraszac && <a href="/zaproszenia">Zaproś osobę</a>}
      <form action={async () => { 'use server'; await signOut({ returnTo: '/' }) }}>
        <button type="submit">Wyloguj</button>
      </form>
    </main>
  )
}

Pole permissions w UserInfo jest opcjonalne i pojawia się tylko wtedy, gdy w panelu WorkOS zdefiniujesz role i uprawnienia. Bez tego dostaniesz undefined, a nie pustą tablicę, co jest częstym źródłem błędu przy sprawdzaniu dostępu.

Surowe SSO doklejone do własnego logowania

Jeśli masz już działające logowanie i chcesz jedynie dołożyć SAML dla klientów firmowych, sięgasz po przestrzeń workos.sso. Adres autoryzacji buduje się z jednego z trzech wykluczających się pól: connection, organization albo provider. Podanie dwóch naraz nie przejdzie kontroli typów.

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

const workos = new WorkOS(process.env.WORKOS_API_KEY, {
  clientId: process.env.WORKOS_CLIENT_ID,
  maxRetries: 3,
  timeout: 30_000
})

const url = workos.sso.getAuthorizationUrl({
  organization: 'org_01H...',
  clientId: process.env.WORKOS_CLIENT_ID!,
  redirectUri: 'https://moja-apka.pl/sso/callback',
  state: podpisanyStan,
  loginHint: 'anna@klient.pl'
})

Po powrocie wymieniasz kod na profil. Odpowiedź ma pola accessToken i profile, a sam profil zawiera id, idpId, organizationId, connectionId, connectionType, email, name, firstName, lastName oraz rawAttributes z surowymi danymi od dostawcy tożsamości.

const { profile, accessToken } = await workos.sso.getProfileAndToken({
  code: kodZUrl,
  clientId: process.env.WORKOS_CLIENT_ID!
})

// WorkOS nie prowadzi bazy uzytkownikow w tym trybie
const konto = await db.uzytkownicy.upsert({
  where: { email: profile.email },
  update: { ostatnieLogowanie: new Date() },
  create: {
    email: profile.email,
    imie: profile.firstName,
    nazwisko: profile.lastName,
    organizacjaId: profile.organizationId,
    zrodloLogowania: profile.connectionType
  }
})

await zalozWlasnaSesje(konto.id)

Wartości connectionType to nazwany zbiór, w którym siedzą między innymi OktaSAML, AzureSAML, GoogleSAML, EntraIdOIDC, JumpCloudSAML, GenericSAML i GenericOIDC. Ta ostatnia para przydaje się, gdy klient ma coś, czego nikt nie przewidział na liście.

Dla klientów publicznych, czyli aplikacji wiersza poleceń, Electrona i aplikacji mobilnych, istnieje getAuthorizationUrlWithPKCE, które zwraca obiekt z polami url, state i codeVerifier. Ten ostatni trzeba przechować i przekazać do getProfileAndToken razem z kodem.

Directory Sync, Audit Logs i webhooki

Directory Sync odbiera dane z katalogu klienta protokołem SCIM i wystawia je pod przestrzenią workos.directorySync. Metoda listUsers przyjmuje directory albo group i zwraca obiekt z automatyczną paginacją.

const uzytkownicy = await workos.directorySync.listUsers({
  directory: 'directory_01H...',
  limit: 100
})

for (const u of uzytkownicy.data) {
  console.log({
    id: u.id,
    idpId: u.idpId,
    email: u.email,
    firstName: u.firstName,
    lastName: u.lastName,
    state: u.state,          // 'active' albo 'inactive'
    organizationId: u.organizationId,
    grupy: u.groups.map((g) => g.name),
    atrybuty: u.customAttributes
  })
}

Pole state przyjmuje wyłącznie wartości active i inactive. Usunięcie osoby z katalogu klienta nie kasuje rekordu po Twojej stronie, tylko zmienia ten znacznik, więc odbieranie dostępu musisz zaimplementować sam.

Audit Logs to strumień zdarzeń zgodności, które klient korporacyjny potem eksportuje albo przesyła do własnego systemu SIEM. Sygnatura createEvent jest pozycyjna: najpierw identyfikator organizacji, potem obiekt zdarzenia.

await workos.auditLogs.createEvent(
  'org_01H...',
  {
    action: 'faktura.pobrana',
    occurredAt: new Date(),
    actor: {
      id: 'user_01H...',
      name: 'Anna Kowalska',
      type: 'user'
    },
    targets: [
      { id: 'inv_2026_08_412', type: 'invoice', name: 'FV/2026/08/412' }
    ],
    context: {
      location: '203.0.113.14',
      userAgent: 'Mozilla/5.0'
    },
    metadata: { kwota: 12400, waluta: 'PLN' }
  },
  { idempotencyKey: crypto.randomUUID() }
)

Klucz idempotencji wygasa po dwudziestu czterech godzinach i powtórzenie żądania z tym samym kluczem zwraca tę samą odpowiedź, co ratuje przed podwójnym wpisem przy ponowieniach. Zmiany po stronie katalogu i użytkowników przychodzą webhookiem, którego podpis weryfikuje constructEvent.

const zdarzenie = await workos.webhooks.constructEvent({
  payload: cialoZadania,
  sigHeader: naglowki['workos-signature'],
  secret: process.env.WORKOS_WEBHOOK_SECRET!,
  tolerance: 300
})

if (zdarzenie.event === 'dsync.user.deleted') {
  await odbierzDostep(zdarzenie.data.idpId)
}

Cennik policzony na przykładzie

Strona workos.com/pricing renderuje się bez JavaScriptu, więc liczby da się odczytać wprost z odpowiedzi serwera. Poniżej wszystkie pozycje, które podaje w chwili pisania.

Procenty w tabeli progów zgadzają się z kwotami: 125 razy 0,8 daje 100, razy 0,64 daje 80, razy 0,52 daje 65. Nie ma tu literówki ani zaokrąglenia, które psułoby rachunek.

Kluczowe zdanie z sekcji pytań na tej samej stronie brzmi tak: każde połączenie kosztuje tyle samo niezależnie od dostawcy tożsamości, rodzaju katalogu i liczby użytkowników końcowych. Połączenie to relacja z jedną grupą użytkowników końcowych, czyli w praktyce jeden klient firmowy. Klient z pięcioma pracownikami i klient z pięcioma tysiącami płacą identycznie.

Policzmy zapowiadany przykład. Dziesięciu klientów korporacyjnych z własnym SSO to dziesięć połączeń w progu pierwszym, czyli 10 razy 125, co daje 1250 USD miesięcznie i 15 000 USD rocznie. Jeśli każdy z nich chce dodatkowo synchronizacji katalogu, dochodzi drugie dziesięć połączeń Directory Sync, kolejne 1250 USD miesięcznie. Razem 2500 USD miesięcznie i 30 000 USD rocznie. Doliczając strumień dzienników audytowych do jednego systemu SIEM za 125 USD i własną domenę za 99 USD, rachunek zamyka się kwotą 2724 USD miesięcznie, czyli 32 688 USD rocznie. Aktywni użytkownicy tych dziesięciu firm nie zmieniają w tym wyliczeniu niczego, dopóki nie przekroczysz miliona miesięcznie.

Trzy rzeczy, których strona nie rozstrzyga, a które trzeba potwierdzić u dostawcy przed podpisaniem. Po pierwsze, przy progach nie jest napisane, czy zniżka obejmuje wszystkie połączenia, czy tylko te powyżej granicy. Przy dwudziestu połączeniach pierwsza interpretacja daje 20 razy 100, czyli 2000 USD, a druga 15 razy 125 plus 5 razy 100, czyli 2375 USD. Różnica wynosi 375 USD miesięcznie i nie da się jej wyprowadzić z treści strony. Po drugie, pozycja o kolejnym milionie użytkowników nie mówi, czy niepełny milion jest naliczany proporcjonalnie, czy zaokrąglany w górę do pełnej kwoty 2500 USD. Po trzecie, plan roczny nazwany Annual Credits nie ma opublikowanej ceny ani stopy zniżki, jest tylko przycisk umawiający rozmowę, więc porównanie rachunku miesięcznego z rocznym jest niewykonalne bez kontaktu z działem sprzedaży.

Dwie rzeczy strona rozstrzyga jednoznacznie na Twoją korzyść. Środowisko testowe jest bezpłatne i wszystkie produkty są w nim dostępne, więc połączenia zestawione do testów nie generują rachunku. Karta płatnicza jest potrzebna dopiero przy przejściu na produkcję. Aktywny użytkownik jest zdefiniowany jako ten, który w danym miesiącu kalendarzowym wykonał jakąkolwiek akcję, na przykład rejestrację, logowanie albo zmianę profilu.

WorkOS a Clerk, Auth0, Kinde i Better Auth

Porównanie ma sens tylko wtedy, gdy zestawia się właściwe produkty. Surowe SSO od WorkOS nie ma odpowiednika u pozostałych, bo tam SSO jest funkcją planu, a nie osobno rozliczaną usługą.

Różnica, która wychodzi z tej tabeli, sprowadza się do pytania, co rośnie razem z rachunkiem. U Clerka, w Auth0 i w Kinde rośnie liczba osób, które się logują. W WorkOS rośnie liczba firm, którym sprzedałeś. Produkt konsumencki z dwustoma tysiącami użytkowników i zerem klientów korporacyjnych zapłaci w WorkOS zero, a u konkurencji sporo. Produkt B2B z tysiącem użytkowników rozłożonych na czterdzieści firm zapłaci w WorkOS za same połączenia SSO od 3200 do 4175 USD miesięcznie, zależnie od tego, jak czytać próg zniżki, a u konkurencji tyle, ile kosztuje tysiąc aktywnych użytkowników, czyli nieporównywalnie mniej, o ile plan w ogóle obejmuje SAML.

Better Auth stoi w tym zestawieniu osobno, bo nie jest usługą. Tabele użytkowników i sesji trzymasz u siebie, na przykład w Supabase albo w dowolnej innej bazie, a za SAML i SCIM płacisz czasem swojego zespołu zamiast abonamentu. To odwrotna strona tego samego wyboru: brak rachunku rosnącego z liczbą klientów w zamian za utrzymywanie integracji z każdym kolejnym dostawcą tożsamości.

Czego WorkOS nie załatwi za Ciebie

Przywiązanie do dostawcy jest pełne i nie da się go zmiękczyć. Otwarte na licencji MIT są wyłącznie biblioteki klienckie. Usługa, która parsuje asercje SAML, przechowuje konfiguracje połączeń i wystawia tokeny, działa tylko u dostawcy. Nie ma wariantu instalowanego u siebie ani ścieżki eksportu konfiguracji do innego narzędzia. Wyjście z WorkOS oznacza zestawienie od nowa każdego połączenia z każdym klientem, co przy trzydziestu klientach jest projektem na kwartał, i to po Twojej stronie oraz po stronie działów IT tych klientów.

Złożoność SAML nie znika, tylko przesuwa się o jeden krok. Admin Portal pozwala administratorowi klienta samodzielnie wpisać metadane swojego dostawcy tożsamości, co realnie oszczędza wymianę maili. Ale mapowanie atrybutów na role w Twojej aplikacji, obsługa rotacji certyfikatów podpisujących, decyzja o tym, czy logowanie inicjowane po stronie dostawcy jest dopuszczalne, oraz reguły przypisywania nowych osób do organizacji zostają po Twojej stronie. Directory Sync przynosi dane, nie decyzje: dostajesz listę grup i musisz sam ustalić, że grupa Finance-Admins mapuje się na uprawnienie do faktur.

Rachunek rośnie skokowo, a nie płynnie. Każdy podpisany klient korporacyjny z SSO to plus 125 USD miesięcznie od dnia zestawienia połączenia, niezależnie od tego, ile ten klient płaci Tobie. Przy kliencie płacącym 300 USD miesięcznie to czterdzieści procent przychodu z niego oddane jednemu dostawcy. Przy kliencie płacącym 10 000 USD to szum. Ten stosunek trzeba policzyć na własnym cenniku, zanim SSO trafi do oferty jako dodatek bez dopłaty.

Dla prostego produktu konsumenckiego WorkOS jest przerostem formy. Milion aktywnych użytkowników bez opłaty brzmi jak najlepsza oferta na rynku i w liczbach nią jest, ale płacisz za nią sprzężeniem z zamkniętą usługą i modelem organizacji, którego nigdy nie użyjesz. Jeśli w Twoim produkcie nie ma pojęcia firmy, do której należy użytkownik, połowa API WorkOS jest martwa.

Typowe błędy

Instalacja pakietu workos zamiast @workos-inc/node. Ta pierwsza nazwa należy do narzędzia wiersza poleceń z innego repozytorium i nie zawiera klienta API.

Mieszanie przestrzeni workos.sso i workos.userManagement w jednej ścieżce logowania. Zwracają różne obiekty, Profile i User, o różnych polach, i są osobno rozliczane. Wybierz jedną ścieżkę i trzymaj się jej.

Sprawdzanie uprawnień przez permissions.includes(...) bez zabezpieczenia. Pole permissions w UserInfo jest opcjonalne i przy braku skonfigurowanych ról ma wartość undefined, więc wywołanie metody na nim wywróci komponent serwerowy.

Szacowanie kosztu przez liczbę użytkowników. W trybie Enterprise SSO liczy się liczba połączeń, a klient z pięcioma tysiącami pracowników kosztuje dokładnie tyle samo, co klient z pięcioma.

Liczenie jednego klienta jako jednego połączenia, gdy korzysta zarówno z SSO, jak i z Directory Sync. To dwa osobno rozliczane połączenia, więc 250 USD miesięcznie zamiast 125.

Wyciąganie wniosków z liczby połączeń zestawionych w środowisku testowym. Środowisko testowe jest darmowe i nie odzwierciedla rachunku produkcyjnego.

Instalacja na Node starszym niż 22.11.0. Pole engines w pakiecie jest ustawione twardo i przy ścisłej konfiguracji menedżera pakietów instalacja się nie powiedzie.

Poleganie na zawartości koła instalacyjnego z PyPI przy audycie licencji. W paczce workos dla Pythona nie ma pliku licencyjnego, jest tylko pole License-Expression w metadanych i plik LICENSE w repozytorium.

FAQ

Czy AuthKit jest darmowy?

Do miliona aktywnych użytkowników miesięcznie tak, zgodnie z cennikiem dostawcy. Aktywny użytkownik to taki, który w danym miesiącu kalendarzowym wykonał jakąkolwiek akcję, na przykład rejestrację, logowanie albo zmianę profilu. Powyżej tego progu każdy kolejny milion kosztuje 2500 USD miesięcznie, przy czym strona nie precyzuje, czy niepełny milion jest liczony proporcjonalnie.

Ile zapłacę za dziesięciu klientów korporacyjnych z własnym SSO?

Dziesięć połączeń w pierwszym progu, czyli 10 razy 125 USD, daje 1250 USD miesięcznie i 15 000 USD rocznie. Jeśli ci sami klienci mają korzystać z synchronizacji katalogu, to kolejnych dziesięć połączeń i drugie 1250 USD miesięcznie. Liczba pracowników w tych firmach nie wpływa na kwotę.

Czy da się uruchomić WorkOS na własnym serwerze?

Nie. Na licencji MIT udostępnione są tylko biblioteki klienckie dla Node, Pythona, Ruby, Go, PHP i Elixira. Usługa przetwarzająca logowanie jest zamknięta i hostowana wyłącznie przez dostawcę, bez wariantu instalowanego lokalnie.

Czym różni się połączenie od użytkownika?

Połączenie to relacja między WorkOS a jedną grupą użytkowników końcowych, czyli w praktyce jeden klient firmowy z jednym dostawcą tożsamości. Cennik podaje wprost, że każde połączenie kosztuje tyle samo niezależnie od dostawcy, rodzaju katalogu i liczby użytkowników po drugiej stronie.

Czy WorkOS ma sens przy zwykłej aplikacji konsumenckiej?

Rzadko. Jeśli w produkcie nie ma pojęcia organizacji, do której należy użytkownik, korzystasz z niewielkiego wycinka możliwości i płacisz za to trwałym sprzężeniem z zamkniętą usługą. Przy takim profilu prościej wypada biblioteka trzymająca dane u Ciebie albo usługa rozliczana za użytkownika.

Czy licencja MIT obejmuje całe WorkOS?

Nie, obejmuje wyłącznie kod klientów. Pakiet @workos-inc/node w wersji 10.10.0 ma MIT w polu license w rejestrze npm, plik LICENSE w paczce i ten sam plik w repozytorium, więc pod tym względem jest czysto. Serwerowa część usługi nie ma opublikowanego kodu ani licencji otwartej.