Stytchは、Webサービスやアプリに顧客向けの認証機能を組み込むためのマネージドサービスです。APIやSDKを使って、パスワードに頼らないログイン、MFA（多要素認証）、セッション管理などを実装できます。
一方で、Stytchには一般消費者向けの「Consumer Authentication」と、法人顧客を持つSaaS向けの「B2B Authentication」があります。どちらも外部ユーザーの認証を扱いますが、利用者の管理単位や必要になる機能は異なります。自社従業員の社内システムへのログインを管理するworkforce向け製品と混同しないことが、選定の第一歩です。
Stytchの中心的な役割は、「誰がログインしているか」を確かめ、その状態を安全に維持することです。認証画面を含む構築済みUIコンポーネント、画面を自社で設計しやすいヘッドレスSDK、APIを直接利用する方法から、開発方針に合う組み込み方を選べます。
Consumer Authenticationでは、メールやSMSなどを利用するOTP、メールのリンクからログインするマジックリンク、端末の生体認証などを活用するパスキーに対応します。ログイン後はセッショントークンを使って状態を確認でき、セッションの更新や失効もAPIから扱えます。ユーザーに再ログインを求める頻度と安全性のバランスを、アプリ側の要件に合わせて設計しやすい仕組みです。
B2B Authenticationでは、個人ユーザーだけでなく、契約企業などを表すorganizationと、その所属者であるmemberを管理します。企業単位でログインポリシーや接続を扱うSaaSに適した構造です。管理APIやSDKを使って、organization、member、sessionの作成・参照・更新といったライフサイクルをアプリの業務フローに組み込めます。Dashboardから運用担当者が確認・管理する方法もあります。
B2B Authenticationでは、企業顧客から求められやすいSSO、SCIM、RBACを利用できます。ただし、3つは同じ機能ではありません。
認証は本人確認、authorization（認可）は操作権限の判定です。Stytchが認証やRBACの土台を提供しても、「どの役割にどの操作を許すか」というルールは自社のサービス設計に基づいて決める必要があります。また、退職や契約終了時にアクセスを止める流れも、SCIMの有無だけでなく、自社DBや業務処理を含めて確認します。
StytchはConsumer AuthenticationとB2B AuthenticationでMFAを扱えます。さらに、通常のログインでは追加認証を省き、重要な操作の直前だけ本人確認を追加するステップアップ認証にも利用できます。たとえば、決済情報の変更や管理者操作など、被害が大きくなりやすい場面に追加の確認を置く考え方です。
MFAを有効にするだけで運用が完成するわけではありません。どのユーザーに必須とするか、紛失した認証手段をどう復旧するか、管理者がどの条件で解除できるかも決める必要があります。セッションについても、有効期間、更新条件、端末紛失時の失効方法を設計します。StytchのAPIで更新や失効を実行できても、実行する条件を定めるのは導入側です。
Stytchは、自社サーバーへソフトウェア一式を導入して運用するself-hosted型ではなく、Stytchが提供する基盤をAPIやSDKから利用するマネージド型です。認証機能を一から構築する範囲を減らし、開発チームがアプリ固有の体験や業務ロジックに集中しやすい点が利点です。認証処理とあわせて、不正利用対策やセッションセキュリティもサービス選定の対象になります。
ただし、マネージド型でも責任がすべて提供元へ移るわけではありません。APIキーやシークレットの保管、権限設計、設定変更の承認、障害時の連絡手順、アプリ側のログ管理は自社で整える必要があります。利用地域や法務・セキュリティ要件がある場合は、公開情報だけで判断せず、必要な条件を整理したうえでサポート窓口へ確認するのが安全です。
Stytchの料金は、単一の月額だけでなく、利用者数や接続数など複数の要素で考えます。Consumer Authenticationの利用規模を表すMAU、B2Bで利用するSSOまたはSCIMのconnection数、機械間通信に使うM2M token、見た目を整えるadd-onは、それぞれ異なる課金単位です。無料枠があっても、ほかの項目まで無料になるとは限りません。
| 費用項目 | 内容 |
|---|---|
| monthly_active_users | self-service pricingでは10,000 monthly active usersが無料枠に含まれる。 |
| Enterprise SSO接続 | self-service pricingではSSOまたはSCIM connectionが5件含まれ、追加connectionは1件あたり月125米ドルと案内される。 |
| 機械ID・token | self-service pricingでは1,000 M2M tokensが無料枠に含まれる。 |
| addon | email customizationとStytch branding removalは月99米ドルのadd-onとして案内される。 |
注意
料金情報は2026年8月7日に確認したGLOBAL向け公式料金を基準にしています。市場、通貨、契約周期、add-onの条件は変更される可能性があるため、契約前に最新情報を再確認してください。
Stytchは、顧客向けアプリへ認証を早く組み込みたいチームや、パスキー、マジックリンク、OTPなど複数のログイン方法を提供したいサービスに向いています。法人向けSaaSでorganization単位の管理、Enterprise SSO、SCIM、RBACが必要な場合も候補になります。UIコンポーネントで導入を早めつつ、必要に応じてヘッドレスSDKやAPIで体験を作り込める点も検討材料です。
反対に、認証基盤を自社環境へself-hostedで配置することが必須なら、前提が合いません。また、社内従業員のworkforce ID管理だけを目的にする場合も、外部ユーザー向けのStytchをそのまま当てはめず、対象ユーザーを整理する必要があります。細かな権限モデルや既存システムとの同期が複雑な場合は、SDKの機能一覧だけでなく、実際のorganization構造と退会・削除フローを試作して判断するとよいでしょう。
Q.Stytchは一般消費者向けと法人向けの両方に使えますか？
A.はい。一般消費者向けにはConsumer Authentication、法人顧客を持つSaaS向けにはB2B Authenticationがあります。後者ではorganizationとmemberを単位に管理し、SSO、SCIM、RBACなどを利用できます。
Q.Stytchを使えば認証画面を自作しなくてもよいですか？
A.構築済みUIコンポーネントを利用できます。一方、独自の画面や操作体験が必要な場合は、ヘッドレスSDKやAPIを使う方法も選べます。
Q.Stytchはself-hostedできますか？
A.この記事の対象であるStytchは、APIやSDKから利用するマネージドサービスです。自社環境へ認証基盤一式を配置するself-hosted型とは、導入と運用の前提が異なります。
Q.MFAを導入すればセキュリティ対策は十分ですか？
A.MFAは重要ですが、それだけでは十分とは限りません。復旧手順、セッションの有効期間と失効、APIキーの管理、権限変更の運用もあわせて設計する必要があります。
Stytchは、外部ユーザー向けの認証をAPIやSDKで組み込めるマネージドサービスです。Consumer AuthenticationではOTP、マジックリンク、パスキーなどを、B2B Authenticationではorganization管理、SSO、SCIM、RBACなどを扱えます。
選定時は、B2CとB2B、認証と認可を分けて考えることが重要です。さらに、MAUやconnectionなど異なる料金単位、MFAとセッションの運用、自社が担う設定・権限管理まで確認すると、自社の用途に合うか判断しやすくなります。
確認日: 2026-08-07（記載の各公式ページで確認。価格などは変わることがあります）
Stytch