Skip to content

DNET_MultiSidedPlatform

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

マルチサイド・プラットフォーム

概要

  • 多数のサイド（＝グループ）にまとわりつかれたプラットフォームの意味。

    • シングルビジネスモデルからマルチビジネスモデルへ
    • 2つ以上の顧客グループを互いに引き合わせる＝マッチメイク
    • 相互依存の関係にある２つのグループをつなぎ合わせるプラットフォーム

  • マルチサイド・プラットフォームとして機能するであろう認証サイト（IdP + STS）、
    多用途認証サイト（Multi-purpose Authentication Site）の
    ユースケースをいろいろと考えている。

認証サイト（IdP + STS）

多用途認証サイト（Multi-purpose Authentication Site）

  • User・Client（ = 認証サイトのクライアント）に、認証結果として、JWTアサーションを発行する。
  • これにより、複数のUser・Clientを紐つけるマルチサイド・プラットフォームとして機能する。

IdP

IdPはUser認証を行い、複数のUserを識別できる。

STS

認証・認可

  • また、OAuth2.0 などの STS をサポートすれば、

    • User認証だけでなく（Authorization Codeグラント種別、Implicitグラント種別）、
    • Client認証（Webサイトの認証）も可能（Client Credentialsグラント種別）

  • 認証・認可の結果として、JWTアサーションをClient・UserAgentに発行する。

  • OAuth2.0で認証・認可云々の話はコチラ（OAuth の該当節）を参考。

Claimの連携

処理に必要なClaim属性値をClient・UserAgentに連携する。

User・Client

User・Clientを特定するには、

  • 認証サイト（IdP + STS）
  • Client（Webサイト）
  • UserAgent（WWWブラウザなど）

間で、認証サイト（IdP + STS）がClient・UserAgentに発行したJWTアサーションを交換し合う。

User

Userは、OAuth2.0のAuthorization Code・Implicitグラント種別など、
認証連携プロトコルを使用して、単一のIdPで認証され、STSからJWTアサーションを取得する。

Client

Clientは、OAuth2.0のClient Credentialsグラント種別を使用して、STSからJWTアサーションを取得する。

マルチサイド・プラットフォーム

認証サイト（IdP + STS）をマルチサイド・プラットフォームとして機能させ、
User・Client、外部サービスを連携させる方法をいろいろと考える。

User・Client（連携方式）

  • JWTアサーションを交換し合うことで、
    • 認証サイト（IdP + STS）
    • Client（Webサイト）
    • UserAgent（WWWブラウザなど）

の間は身元を特定できる。

  • 外部サービスとの連携については、
    • 認証サイトのResources Serverにハブ実装を追加して集約するか、
    • Client・UserAgentから直接利用するかの二択になる。

外部サービス（連携方式）

JWTアサーションを交換できない外部サービスが含まれてくると話は複雑になる。

IdP + STSをサポートする外部サービス

  • 例えば、OAuth 2.0のAuthorization Code・Implicitグラント種別を使用して、
    Client・UserAgentから直接WebAPIを利用するシナリオ。

    • Client・UserAgentが外部サービスを直接利用する場合、外部サービスのTokenを連携する。

    • これには、外部サービスが、Client IDやClient Secretを必要とせず、
      Tokenだけで使用できる必要がある。

    • 以下は、外部サービス → 認証サイト → Client・UserAgentと、Tokenを連携する方法。

      • 外部サービスと連携し、認証サイトはTokenを取得する。

      • Clientは、認証サイトと連携し、TokenをClaimとして要求・取得する。

IdPをサポートしない外部サービス

  • 例えば、基本認証や、OAuth 2.0のClient Credentialsグラント種別を使用して、
    認証サイト（Resources Server）でWebAPIを集約するシナリオ。

    • 通常の外部サービスは、ClientのCredentialsが必要になる。
      なので、認証サイトが、マルチサイド・プラットフォームとして機能する場合、
      認証サイト経由で認証サイトのCredentialsを使用して外部サービスを使用する。

    • このパターンは無駄に認証サイト経由を強いるためイイ方法ではない可能性があるが、
      認証サイト側が価値提案する機能で外部サービスのAPIの粒度を上げることができれば意味がある。

User・Client、外部サービスを連携させるユースケース

認証サイト（ユースケース）

  • 認証サイトは、複数のClientの認証基盤として機能する。
  • 認証サイトは、Client・UserAgentに、JWTアサーションを用いてUser・Clientの認証情報を提供する。

Client（ユースケース）

  • ClientはWebサービスを公開する。
  • Clientが公開したWebサービスは、使用したUser・Clientを適切に識別出来る。
  • Clientは、自分以外のClientとJWTアサーションを交換することによって、
    User・Clientへの申請や請求などの連携処理を実装できる。

外部サービス（ユースケース）

  • IdP + STSをサポートする外部サービス

    • Facebookと連携する場合。

      • Facebookで外部ログイン
      • FacebookのAccessTokenを使用して、Facebookに投稿を行う。

    • StripeのConnect機能で、Standalone Accountを使用するケースなど、
      認証とUser・Clientの接続の機能が外部サービスの内部に実装されているようなケース。

  • IdPをサポートしない外部サービス

    • StripeのConnect機能で、Managed Accountを使用するケースなど、
      認証とUser・Clientの接続の機能が外部サービスの外部にオフロードされているようなケース。

      • この場合、このオフロード処理は、認証サイトが担うため、
        認証サイト経由で、外部サービス（ここでは、StripeのConnect機能）を使用する必要がある。

      • 認証サイトで、外部サービス（ここでは、StripeのConnect機能）のアカウントを
        管理することで、認証サイトは、User・Client、外部サービスを連携させる
        ハブとして機能できる。

参考

移行メモ

  • 元 Wiki には「User・Client」「外部サービス」「認証サイト」「Client」という見出しが 複数あり GitHub Wiki でアンカが衝突するため、括弧で文脈を補って一意にした。
  • マイクロソフト系技術情報 Wiki への URL リンクは、 移行済みの OAuth に張り替えた。
  • 元 Wiki の「Idp」表記は「IdP」に統一した。
  • 本ページは 2020 年時点の検討メモである。

Tags: 移行, 企画, マルチサイド・プラットフォーム, 認証基盤, IdP, STS, OAuth, JWT, ビジネスモデル

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally