Claude Media
Claude Codeのdescopeプラグインで認証実装とAuth0移行を進める
Claude CodeClaude連携チュートリアル

Claude Codeのdescopeプラグインで認証実装とAuth0移行を進める

Descopeプラグインは認証の実装、Auth0・Okta・WorkOSなどからの移行、Terraform、認可スキーマ、認証の静的レビューをスキルとして束ねます。入れ方と移行計画の読み方を説明します。

読了目安 約10分

Descopeプラグインは、認証基盤Descopeの導入と、他社の認証サービスからの移行をClaude Codeに任せるためのスキル集です。マーケットプレイスの説明文には、認証の組み込み、Auth0・Okta・WorkOS・Stytch・PingOneからの移行、Terraform、FGAの認可スキーマ、セキュリティレビュー、BYOSのカスタムUIが並びます。

このうち手を動かす場面が多いのは、新規アプリに認証を足す作業と、Auth0からの乗り換えです。ここでは入れ方、スキルの使い分け、移行スキルが出す計画書の読み方、実行前に絞っておきたい権限を順に説明します。

Descopeプラグインに入っているスキル

プラグインの中身は、GitHubのdescope/skillsリポジトリにあるスキル群です。READMEの「Available Skills」には、次の10個が並びます。

やりたいことスキル
アプリに認証を組み込むスキルdescope-auth
認証・認可の脆弱性を静的に点検するスキルauth-review
プロジェクト設定をコードで管理するスキルdescope-terraform
Auth0から移行するスキルauth0-to-descope
Okta CISから移行するスキルokta-cis-to-descope
WorkOSから移行するスキルworkos-to-descope
Stytchから移行するスキルstytch-to-descope
PingOne CIAMから移行するスキルpingone-to-descope
FGAの認可スキーマを書くスキルdescope-fga-schema
フロー上にReactのカスタム画面を作るスキルdescope-byos-builder

READMEの互換性の節は、Agent Skills形式に対応するエージェントなら動くとしています。Claude Code専用のものではなく、Cursorなど他のエージェントにも同じスキルを入れられます。

Claude Codeへの入れ方

Claude Codeでは、マーケットプレイスを追加してからプラグインを入れます。READMEの手順は次の2行です。

/plugin marketplace add descope/skills
/plugin install descope-skills

入れたあとは、スキルを名前で呼ぶ必要はありません。READMEには「スキルは対応エージェントが自動で読み込む。必要なことを書けばよい」とあり、「Add Descope authentication to my Next.js app」のような依頼文がそのまま例になっています。READMEがスラッシュ形式(/auth-review、/descope-fga-schema)で呼ぶ例を載せているのは、この2つです。

Descopeのプロジェクトが無ければ、先に無料アカウントを作ります。READMEの「Getting Started」は、設定のProjectからProject IDを取る手順を挙げています。Terraformを使う場合は、管理キーもCompany Settingsから発行します。

認証を新規に組み込む(descope-auth)

descope-auth は、フレームワークを検出して、それに合う組み込み手順へ振り分ける作りです。READMEが挙げる対応は次の4つです。

  • Next.js(App RouterとMiddleware)
  • React(保護ルートを持つSPA)
  • Node.jsのバックエンドでのセッション検証
  • Pythonのバックエンドでのセッション検証

扱う認証方式は、メールやSMSのOTP、マジックリンク、パスキー、ソーシャルログインなどのOAuth、企業向けSSO、認証アプリによるTOTP、パスワードです。READMEはパスワードを「従来型で、ほかの方式の代替」と位置づけています。

依頼の書き方は、方式とフレームワークを両方入れると振り分けが早くなります。

Next.js(App Router)のアプリにDescopeでパスキーログインを足して。
未ログインのときは /login に飛ばすMiddlewareも入れて。

ログイン画面が使うフローは、コンソールで先に作る進め方が基本です。READMEは auth0-to-descope の説明にも「コンソール優先(console-first)」と書いており、FlowやWidgetの設定はコンソール側で整えてからコードをつなぐ前提です。

Auth0からの移行(auth0-to-descope)

移行系のスキルは、いきなりコードを書き換えません。READMEは auth0-to-descope の流れを「MCPの確認、移行計画(人間のレビュー)、実行」の3段階とし、手順を飛ばさないと明記しています。

最初に出るMIGRATION-PLAN.mdを読む

計画段階の成果物は、人間が確認するための MIGRATION-PLAN.md です。Auth0を使っているコードの接点を洗い出した結果がここに載り、レビューを経て初めてコードの置き換えが始まります。

READMEが挙げる対応の例は次のとおりです。

Auth0Descope
ActionsDescopeDescope flows
OrganizationsDescopeTenants
Token Vault、CIBADescopeスキル内で個別に扱う対象

計画書では、この対応表のどこまでが自分のアプリに当てはまるかを見ます。Actionsで認証後に独自処理を挟んでいるなら、それがフローのどこに移るのかが焦点です。SDKの置き換え対象にはNext.js、React、Express、Pythonなどが含まれ、読み込むSDKの名前や引数の形は、利用可能ならDescope Docs MCPで確認するとされています。

計画書の確認をプロンプトで固定する

計画段階で止まらず先に進んでしまうのを避けたいなら、依頼文で止め位置を明示します。

nextjs-auth0を使っているこのリポジトリをDescopeに移したい。
まず MIGRATION-PLAN.md だけ作って、コードは変更しないで。
計画を私が確認するまで、実行段階には進まないで。

スキル側も同じ順序を守る設計なので、二重の歯止めになります。計画書を直したいときは、ファイルを直接編集してから「この計画で実行して」と伝えると、人間が直した計画書を前提にできます。

READMEの例文にも「Migrate my Next.js app from nextjs-auth0 to Descope」「How do I replace Auth0 Actions with Descope?」のように、元のSDKや機能名を入れた依頼が並びます。移行元のパッケージ名を書くほど、スキルが接点を拾いやすくなります。

Okta・WorkOS・Stytch・PingOneからの移行

Auth0以外の移行スキルも、同じ「MCPの確認、計画、実行」の3段階を取ります。違うのは移行元の機能をどうDescopeに写すかです。

  • Okta CIS: ホスト型のリダイレクトログインか、埋め込みウィジェットかを検出して、既定の移行経路を選びます。ホスト型ならissuerの設定を差し替えるOIDC互換の経路があります。Sign-On PoliciesはFlowsに、Authorization ServersはResourcesまたはInbound Appsに対応づけられます
  • WorkOS: WorkOSは認証だけでなくB2B向けの機能をまとめて提供する基盤なので、スキルは最初にどの機能を使っているかを洗い出します。AuthKitはDescope Flowsに、OrganizationsはTenantsに、Directory SyncはDescope SCIMに写します
  • Stytch: コンシューマー認証、B2B組織、エンタープライズSSO、不正対策、Connected Appsのどれを使っているかを最初に確認します
  • PingOne CIAM: 顧客向け(CIAM)に限るスキルです。従業員向けのIAMやPingFederate、ForgeRockなどは、明示的に範囲に入れない限りスキルが止まると説明されています。PingOneからはパスワードやハッシュを書き出せないため、初回ログイン時の再設定かパスワードレスに切り替える前提です

WorkOSやStytchについては、各社のMCPをClaudeにつなぐ手順を別の記事にまとめています。移行元のダッシュボードを操作したい場合はWorkOS MCPコネクタやStytch MCPの設定が参考になります。移行スキルが相手にするのはアプリのコードと移行先のDescope側であり、移行元の管理画面を操作するものではない点が違いです。

Terraform・認可・レビュー・BYOS

実装と移行のほかに、運用に寄ったスキルが4つあります。

descope-terraform:設定をコードで管理する

公式のTerraformプロバイダーを使って、Descopeのプロジェクトを管理します。生成対象のリソースは次の3つです。

  • descope_project: 認証方式、RBAC、コネクタ、フロー、設定のすべて
  • descope_management_key: RBACで範囲を絞った管理キー
  • descope_descoper: ロールを割り当てたコンソールのユーザー

READMEが挙げる前提は、Terraform CLIのインストール、有料のDescopeライセンス(Pro以上)、Company Settingsで発行する管理キーの3つです。無料のプロジェクトでは、このスキルは前提を満たしません。

descope-fga-schema:認可の関係を書く

関係ベース(ReBAC)と属性ベース(ABAC)のDSLでFGAのスキーマを書き、適用前にdry runで検証します。データが消える変更には警告が出て、本番のスキーマを書き換える前にユーザーの確認を取ります。要件はDescope Management MCPのインストールと認可です。

auth-review:認証と認可の静的レビュー

DescopeやAuth0に依存しない、ベンダー非依存の静的レビューです。ルートとエンドポイントを洗い出して認可マトリクスを作り、OWASPのWebとAPIのトップ10に沿った脆弱性カタログを当てます。出力は ./auth-review/report-YYYY-MM-DD.md で、深刻度(High / Medium / Low)、CWE、ファイルと行、根拠、修正案が付き、GitHub issueにそのまま貼れる形の本文も含まれます。

READMEは、このスキルを静的で読み取り専用だと説明します。アプリを実行せず、ネットワークの探査もせず、コードを変更せず、issueを直接起票することもありません。リリース前の点検として単独で使えます。

descope-byos-builder:カスタム画面をフローに合わせて作る

Descopeのフローを書き出したJSONから、React用のカスタム画面(BYOS)を生成します。画面名、インタラクションID、入力名をJSONから読み取り、推測では書かないことが鉄則です。ボタンを押しても何も起きない、no handler for screen が出る、サインイン後もセッションが匿名のままといった症状には、19項目の失敗カタログが用意されています。

実行前に権限を絞る

認証の移行は、.env やAPIキーに近い場所で作業します。スキルの実行前に、読ませたくないファイルをdenyルールで外しておくと安全です。Claude Codeの権限ルールは、Read(./.env) のような形でファイル単位に読み取りを禁止できます。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

.claudeignore は効きません。除外したい項目はReadのdenyルールに移します。管理キーやProject IDはコードに埋め込まず、環境変数から読む形で依頼文に書いておくと、生成物の確認もしやすくなります。

使い分けの目安

選び方

どのスキルから始めるか

  • 新規アプリに認証を足す

    descope-auth。フレームワークを依頼文に入れます。

  • 他社サービスから乗り換える

    移行元に合わせて *-to-descope。最初に計画書だけ作らせます。

  • 本番に出す前に点検する

    auth-review。読み取り専用なので、先に回しても影響しません。

  • 設定をチームで共有する

    descope-terraform。Pro以上のライセンスが要ります。

プラグインとして配る側の事情は、プラグイン化の移行手順にまとめています。同じマーケットプレイスの仕組みで入れるDash0プラグインとは、スキルを束ねる点で作りが違います。

よくある質問

Descope以外のAuth0移行にも使えますか

移行先がDescopeであることが前提です。ほかの認証基盤への乗り換えでは、auth-review の静的レビューだけが基盤に依存しません。

まとめ

最初の一歩は、計画書だけを出させる移行スキルか、読み取り専用の auth-review です。どちらもコードを変えないので、出力の粒度がチームの基準に合うかを先に確かめられます。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →