TANASUKE
TANASUKE ACCOUNT / OIDC DOCS

TANASUKE Account の仕組み
— ひとつのアカウントで、すべてのサービスへ —

TANASUKE の各サービス（アプリや管理画面）は、共通の「TANASUKE Account」でサインインします。このページでは、その裏側で動いている仕組み（OIDC・IdP・RP・SDK）を、IT の専門知識がなくても読めるように図で説明します。

01登場人物 — 受付・会員窓口・各施設

たとえるなら、TANASUKE Account は「総合受付」、入会システムは「会員窓口」、各サービスは「施設」です。施設ごとに名簿を作らず、受付で本人確認をひとつにまとめています。
利用者（あなた） TANASUKE Account ＝ IdP（総合受付・身元の正本） 本人確認 ／ 身分証（トークン）の発行 誰がどの施設に入れるか（許可）の台帳 サーバー同士の通行許可（M2M） 入会システム ＝ 会員窓口（RP） サービス A（RP） サービス B（RP） 今後増える施設…（RP） サインイン OIDC IdP（受付） 入会システム（会員窓口・RPのひとつ） RP（各サービス＝施設）
図1. 全体像。利用者は受付（IdP）で本人確認し、各施設（RP）は受付の判断を信頼して入場を許可します。

IdPTANASUKE Account

Identity Provider（身元の提供者）。メールアドレス・氏名・ログイン手段など「その人が誰か」を唯一保持する正本。サインイン画面もここが出します。

RP各サービス

Relying Party（受付を信頼する側）。アプリや管理画面のこと。自前でパスワードを持たず、IdP の判断を信頼して利用者を受け入れます。

RP入会システム

RP のひとつですが特別な役割を持ち、「誰にどの役割（ロール）を与えるか」を決める会員窓口です。

SDK開発キット

各サービスが IdP と正しく会話するための部品。開発者が毎回ゼロから作らずに済み、間違いも防げます（第7章）。

OIDC共通ルール

OpenID Connect。「受付で本人確認し、施設に身分証を渡す」やり取りの世界標準の手順書。Google や Apple のログインも同じ仕組みです。

02サインインの流れ — 施設は受付に確認を頼む

利用者がサービスに入ろうとすると、サービスはいったん受付（IdP）へ案内します。受付で本人確認が済むと「本人です」という身分証（トークン）が発行され、サービスはそれを見て入場を許可します。パスワードやメールの認証コードを扱うのは受付だけです。
利用者のブラウザ サービス（RP） TANASUKE Account（IdP） ① 「サービスを使いたい」 ② 「受付へどうぞ」（案内） ③ 受付でサインイン（メールの認証コード or パスワード） ④ 「確認できました」＋ 引換券（コード） ⑤ 引換券をサービスへ提示 ⑥ サービス⇔受付で引換券を身分証に交換（裏側・HTTPS） ⑦ 身分証（トークン）：誰か／どの役割か／有効期限 ⑧ 入場 OK（サービスの画面へ） パスワード・認証コードを見るのは受付（IdP）だけ。 サービス側には保存されません。
図2. サインインの流れ（OIDC 認可コードフロー）。⑥⑦は利用者からは見えないサーバー同士のやり取りです。

ポイント

03身元の正本は IdP — サービスは「写し」しか持たない

「その人が誰か」の情報は TANASUKE Account にしかありません。各サービスは受付から渡された不変の ID（sub）と必要最小限の写し（表示名など）を持つだけです。メールアドレスの変更や退会は受付で一度行えば、全サービスに反映されます。
TANASUKE Account（正本） ■ 不変ID（sub）　01M2AT…（生涯変わらない） ■ メールアドレス（主・予備）／確認済みか ■ 氏名・ニックネーム・写真 ■ ログイン手段（認証コード／パスワード／2段階） ■ 有効／停止／退会　■ 各サービスへの許可と役割 ■ 監査ログ（いつ誰がどこにサインインしたか） 入会システム（写し） sub ＋ 会員情報（所属・電話・登録完了日）＋ 役割の決定 サービス A（写し） sub ＋ 表示名 ＋ このサービス内のデータ サービス B（写し） sub ＋ 表示名 ＋ このサービス内のデータ サインイン時・変更時に 最新の写しを渡す
図3. 正本は IdP にひとつ。各サービスは不変ID（sub）をキーに写しを持つだけなので、名寄せの食い違いが起きません。
できごとどこで行う各サービスへの反映
メールアドレスの変更TANASUKE Account のマイページ次回サインイン時、または通知（プロビジョニング）で自動反映
パスワード変更・2段階認証TANASUKE Accountサービス側は関与しない（そもそも保持していない）
退会・利用停止入会システムで申請 → IdP で停止全サービスで即座にサインイン不可・既存セッションも失効
サービス固有の設定・データ各サービスそのサービス内で完結（IdP は関知しない）

04ロール（役割）— 定義はサービス、決定は入会システム、配布は IdP

「管理者」「スタッフ」「メンバー」のような役割の種類は各サービスが決めます（サービスごとに必要な役割は違うため）。それをIdP に登録しておき、誰がどの役割かは入会システム（会員窓口）が決めます。決まった役割は IdP の台帳に記録され、サインインのたびに身分証に載せて各サービスへ届きます。
サービス A（RP） 役割の「種類」を定義 例: owner / admin / staff / member （ロールスキーマ） TANASUKE Account（IdP） 役割台帳（grant） 「田中さん × サービスA ＝ admin」 「田中さん × サービスB ＝ member」 入会システム（会員窓口） 「誰に」「どの役割」かを決定 管理画面で人ごとに設定 （入会・昇格・停止） サービス A（RP） 身分証の rp_role を見て 画面や操作を出し分ける 例: admin なら管理メニュー サービス B（RP） 同じ人でも役割は サービスごとに違ってよい 例: B では member ① 役割の種類を登録 （SDK: roleSchema push） ② 人ごとの役割を決めて登録 （M2M: idp:write.grants） ③ サインイン時に rp_role として配布 ③ 変更時は通知（webhook）でも配布
図4. 役割の「種類」はサービス、「誰がどれか」は入会システム、「記録と配布」は IdP。三者の責任がはっきり分かれています。
  1. サービスが役割の種類を決める。「このサービスには owner／admin／staff／member がある」と宣言し、SDK で IdP に登録します（サービスの都合で増減できます）。
  2. 入会システムが人に役割を割り当てる。会員窓口の管理画面で「田中さんはサービスAの admin」と決めると、IdP の台帳（grant）に書き込まれます。
  3. IdP がサインインのたびに配る。身分証（トークン）の rp_role に役割が載って各サービスへ届きます。役割が変わったときは IdP から各サービスへ通知（provision webhook）も飛びます。
  4. 各サービスは受け取った役割で出し分ける。管理メニューの表示や操作の可否をこの役割で判断します。サービスが独自に役割を書き換えることはしません（正本は IdP）。

※ 入会システムの管理者自身も IdP でサインインします。「入会システムでの役割＝サービスAでの役割」ではなく、サービスごとに独立して設定できます。

05サーバー同士の通信（M2M）— 人がいなくても安全に、許可は IdP が判断

サービス同士がデータをやり取りする場面（例: サービス A が入会システムの会員情報を参照する）では、人のサインインは使いません。代わりにサービス自身が IdP から「通行許可証」を受け取り、相手サービスに提示します。どのサービスが、どのサービスの、何を読めるかは IdP の許可表（ポリシーと scope）で決まり、勝手に広げられません。通信はすべて HTTPS（暗号化）なので、別のサーバー・別の拠点にあっても中身を盗み見・改ざんできません。
サーバー X（例: 大阪） サービス A（呼び出す側） サーバー Y（例: 東京） 入会システム（データを持つ側） TANASUKE Account（IdP） 許可表（ポリシー） A → 入会: membership:read.profile ✔ A → 入会: 削除 ✘（未許可） ① 通行許可証を申請 （client_credentials ＋ scope） ② 許可表に合えば発行（期限つき） ③ 許可証を添えて要求　—— HTTPS（暗号化）—— ④ 許可証が本物か IdP に照会 （introspection） ⑤ 許可された範囲のデータだけ返す 許可証は短時間で失効し、範囲（scope）を超える要求は拒否されます。「どのサービスが何をしたか」は IdP に記録されます。
図5. M2M（machine to machine）。呼び出す側は IdP から許可証を得て、受ける側は IdP に本物か照会します。判断はどちらも IdP。

安全に疎通できる理由

通信は常に HTTPS（TLS）。証明書は正規の認証局（Let's Encrypt）発行で、経路上で中身を読まれたり書き換えられたりしません。サーバーが別でも同じです。

認可を IdP が担保する理由

「A が入会システムの会員プロフィールを読める」という許可は IdP の許可表にだけ書かれ、各サービスの設定では増やせません。鍵（client secret）を持っていても、許可表にない範囲は取れません。

許可証（scope）の粒度

「読む」「書く」「削除」を分けて許可します。例: membership:read.profile（読む）、idp:write.grants（役割の更新・自分のサービスの分だけ）。

人の操作と組み合わせる場合

「田中さんの代わりに A が入会システムを読む」ときは、田中さんの身分証と A の許可証を両方添えます（トークン交換）。本人が許可していない範囲は読めません。

06各サービスは独立して動く — 同期は「自分のルール」で

各サービスは自分のデータベースと自分の業務ルールを持ち、それぞれ独立して動きます。IdP に頼るのは「誰か」「役割は何か」の確認だけです。IdP の情報をいつ・どう取り込むか（同期）は、サービスごとに都合のよい方法を選びます。
TANASUKE Account（IdP） 身元・役割の正本 サービス A 同期方式: サインイン時に取り込む 自分のDB・自分の業務ルール （IdP に無い情報はここ） 受付が止まっても既存の作業は継続 サービス B 同期方式: 通知（webhook）で即時反映 自分のDB・自分の業務ルール 退会通知を受けたら自分の手順で データを整理する 入会システム 同期方式: 双方向（決めた役割を IdP へ） 会員台帳・入会条件・退会手続き 「本登録が済んだか」を IdP から問い合わせられる サインイン時に最新の写し 変更を通知（webhook） 役割の登録 ／ 本登録状況の照会
図6. 同じ IdP を使いながら、取り込み方はサービスごとに違ってよい。共通なのは「OIDC で確認する」というルールだけ。

独立しているとは

同期の選び方（目安）

方式向いている場面反映の速さ
サインイン時に取り込む表示名や役割を画面に出すだけの一般的なサービス次回サインイン時
通知（webhook）を受ける退会・停止を即座に反映したい、データ整理が必要なサービス数秒以内（失敗時は IdP が再送）
必要なときに照会（M2M）管理画面で一覧を出すとき、他サービスの情報を参照するときそのつど最新

07SDK — 各サービスが安全に IdP と話すための部品

ここまでの手順（サインインの案内、引換券の交換、許可証の取得、本物かの照会、役割の登録、通知の受け取り）を毎回ゼロから作ると間違いが起きます。SDK はこれらをできあがった部品として提供し、開発者は数行の設定で組み込めます。
サービス（RP）の中身 業務ロジック画面・データ TANASUKE IdP SDK OIDC・M2M・通知 役割登録 を代行 TANASUKE Account（IdP） 世界標準（OIDC）の窓口 HTTPS（標準手順）
図7. SDK は各サービスの中で IdP との会話を代行する部品。業務ロジックは IdP の細かい手順を知らなくてよい。

Laravel（PHP）向け

tanasuke/idp-sdk。サインイン（RP）、許可証の検証（リソースサーバー）、他サービス呼び出し（サービスクライアント）、役割スキーマ登録、役割同期をひとまとめに提供。

Node / TypeScript 向け

@tanasuke/idp-sdk。同じ機能を Next.js や Express などの JavaScript 製サービス向けに提供。

新しいサービスを追加するとき

① IdP の設計書（manifest）にサービスを1件追記 → ② 発行された鍵をサービスの設定に入れる → ③ SDK を組み込み、役割の種類を登録。これで「TANASUKE Account でサインイン」対応になります。

08現在の構成と用語集

現在の構成

役割URL説明
IdPaccount.official.tanasuke.com
account-api.official.tanasuke.com		TANASUKE Account。サインイン画面・マイページ・管理画面（サービス登録、役割台帳、監査ログ、SMTP など）。
RPmembership.official.tanasuke.com
membership-api.official.tanasuke.com		入会システム（会員窓口）。会員登録・プロフィール・退会申請・人ごとの役割設定。
SDKtanasuke-idp-sdk ／ tanasuke-idp-sdk-js各サービス組み込み用の部品（GitHub で管理）。

証明書はすべて正規の認証局発行（HTTPS）。サーバーは自社管理で、送信メールは no-reply.tanakadaisuke@ptop.space から届きます。

用語集（やさしい言いかえ）

用語言いかえひとこと
OIDC（OpenID Connect）受付で本人確認して施設に身分証を渡す手順書世界標準。Google・Apple のログインと同じ方式。
IdP（Identity Provider）総合受付・身元の正本TANASUKE Account のこと。
RP（Relying Party）受付を信頼する施設各サービス・アプリ。入会システムも RP のひとつ。
sub生涯変わらない会員番号メールが変わっても同じ人だと分かる。
トークン（ID／アクセス）身分証・入場券誰か・役割・有効期限が書かれた期限つきの券。
認可コード引換券受付で受け取り、サービスが裏で身分証に交換する。
PKCE引換券のすり替え防止途中で券を盗まれても交換できないようにする仕掛け。
scope許可の範囲「読む」「書く」「削除」などを細かく分ける。
M2M（client_credentials）サーバー同士の通行許可人がいなくても、許可表の範囲でやり取りできる。
introspection券が本物か受付に確認受け取った側が IdP に照会する。
grant役割台帳の1行「誰 × どのサービス ＝ どの役割」。
rp_role身分証に書かれた役割サービスごとに違ってよい。
provision webhook変更の通知役割変更・退会などを IdP から各サービスへ知らせる。
SSO（シングルサインオン）一度の受付で全施設へ受付が「確認済み」を覚えている。
manifestIdP の設計書どのサービスがあり、どの許可があるかを書いたファイル。変更履歴が残る。

よくある質問

各サービスにパスワードは保存されていますか？

されていません。パスワードや認証コードを扱うのは TANASUKE Account だけです。サービスが受け取るのは期限つきの身分証（トークン）だけです。

あるサービスの役割を変えると、他のサービスにも影響しますか？

しません。役割はサービスごとに独立した台帳の行です。入会システムで「サービスAは admin、サービスBは member」のように別々に設定できます。

IdP が止まったらすべて使えなくなりますか？

新しいサインインと役割の変更は待ちになりますが、サインイン済みの利用者はそのサービス内の作業を続けられます。各サービスは自分のデータで動いているためです。

別の会社のサーバーにあるサービスとも連携できますか？

できます。通信は HTTPS で暗号化され、許可は IdP の許可表で管理されるため、サーバーの場所や運営者が違っても同じルールで安全に疎通できます。

Google や Apple のアカウントでサインインできますか？

仕組みとしては対応済み（IdP が Google／Apple を「上位の受付」として受け入れる）で、設定を入れれば有効化できます。現在は無効です。