「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
マルチサイド・プラットフォームとして機能するであろう認証サイト、
汎用認証サイト（Multi-AuthSystem）のユースケースをいろいろと考えている。
認証サイト †
汎用認証サイト（Multi-AuthSystem）
- User・Client（ = 認証サイトのクライアント）に、認証結果として、JWTアサーションを発行する。
- これにより、複数のUser・Clientを紐つけるマルチサイド・プラットフォームとして機能する。
IdP †
IdPはUser認証を行い、複数のUserを識別し、紐つける事ができる。
STS †
また、OAuth2.0 などの STS をサポートすれば、
- User認証だけでなく（Authorization Codeグラント種別）、
- Client認証（Webサイトの認証）も可能（Client Credentialsグラント種別）
User・Client †
User・Clientを特定するには、
間で、認証サイトがClient・UserAgent?に発行したJWTアサーションを交換し合う。
User †
Clientは、OAuth2.0などの認証連携プロトコルを使用して、
Userは、単一のIdPで認証され、STSからJWTアサーションを取得する。
Client †
Clientは、OAuth2.0のClient Credentialsグラント種別を使用して、STSからJWTアサーションを取得する。
マルチサイド・プラットフォーム †
User・Client †
- JWTアサーションを交換し合うことで、User・Clientの身元を特定できる。
- 処理に必要な属性値は連携する必要がある。
外部サービス †
通常の外部サービス †
- 通常の外部サービスは、ClientのCredentialsが必要になる。
なので、認証サイトが、マルチサイド・プラットフォームとして機能する場合、
認証サイト経由で認証サイトのCredentialsを使用して外部サービスを使用する。
- このパターンは無駄に認証サイト経由を強いるためイイ方法ではない可能性があるが、
認証サイト側が価値提案する機能で外部サービスのAPIの粒度を上げることができれば意味がある。
- User・Clientが外部サービスを直接利用する場合、
外部サービスのTokenを連携する（Tokenだけで使用できる必要がある）。
外部サービス自体が、マルチサイド・プラットフォームである場合、 †
- この場合は、認証サイト経由で、
マルチサイド・プラットフォームの外部サービスを使用する必要がある。
例えば、StripeのConnect機能などがこのパターンである。
- User・Clientを紐つける事ができるは、認証サイトだけであり、
異なる組織のClientの紐付けは認証サイト側でしかできない。
- UseCase?のイメージは、複数のClientの認証基盤として機能し、Clientの管理者はサービスを公開する
公開したサービスは、User・Clientから使用されるため、使用者に適切に課金することが出来る。
- この機能は、UserStore?を使用可能なResourcesServer?に実装しても良いが、
その場合、ResourcesServer?に公開するデータをフィルタする仕組みが必要になってくる。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
