MS_ClaimsBasedAuthentication
- 戻る（認証基盤、その他、開発の色々（
MS_MiscDevelopmentTopics.md））
ID 連携とは、
- アイデンティティ（ID）＆フェデレーション（ID 連携）
- クレームベース認証
クレームセットを使用して認証する。
- ＝ ユーザを特徴づける属性情報
- ≠ ユーザ ID（Identifier）
このユーザ属性情報をクレームセットに
同梱してユーザに渡す（＝ ID 連携）。
- アプリ側に重複したユーザ ストアを持たせない。
- 同期不要。一元管理された、最新の ID を利用する。
- パスワードをユーザに分散管理させたくない。
- クラウド上のサービスを自社内で認証したい。
- コンシューマー向けアプリを SNS 認証で利用させたい。
SAML / WS-FED とか、
OpenID / OAuth / OpenID Connectなど、
大体、認証後に発行するトークン（クレーム）的なものを使用して
認可（認証）する仕掛けになっている。
-
IdP（Identity Provider）
認証を行う。 -
STS（Security Token Service）
トークン（クレーム）の発行を行う。クレームは、- IdP（Identity Provider）によって発行され、
- STS（Security Token Service）によって
- 1 つ以上の値が指定されてから、
- STS が発行するセキュリティ トークンにパッケージ化される。
-
SP（Service Provider）
認可を行う。
この STS（Security Token Service）が発行する
トークン（クレーム）的なものにより、認証（IdP）と認可／認証（SP）を分離できる。
-
分散型の認証方式を提供するオープンな認証システムと言える
（これを世の中では認証連携（ID フェデレーション）と呼んでいる）。 -
OAuthに関しては、トークンとクレームの発行が分離されている。
トークン発行までが OAuth の仕様なので、
認証用のクレーム発行は拡張仕様を実装する必要がある
（その拡張仕様が OpenID Connect である）。
ある「主体」（subject）又は資源が、
「主張」（claim）どおりであることを確実にする特性。
UserID、メアド、ユーザ名等。
主体の主張、主体の属性。
- 本人性を確認する
- ID／パスワード認証、生体認証、ワンタイム パスワード認証
あるリソースへアクセスするための権限を与える（認証後のアクセス制御）。
フェデレーションは、「連携」の意味。
-
SAML、OpenID などの認証・認可に関わるプロトコルや
その仕組みの総称として使われることがある。 - ID やパスワードの発行者（IdP：Identity Provider）と、
ID の利用者（RP：Relying Party）の 2 つに役割を分担する。 - ID 連携（ID フェデレーション）
- IdP と SP の間でユーザーアカウントを紐付けることを意味する。
- IdP と SP は信頼関係を結んだ後、アカウント連携を行う必要がある。
それによって、以下の様な利点が発生する。
- サービス プロバイダ側で直接認証（ID やパスワードの入力）を行っていない。
∴ サービス プロバイダへのネットワーク経路上をパスワードが流れない。 - サービス プロバイダが直接アイデンティティ プロバイダと通信を行っていない。
∴ アイデンティティ プロバイダとサービス プロバイダは
別々のネットワークに存在してもよい。
イントラネット上のアイデンティティ プロバイダを利用して、- クラウド上のサービス プロバイダへセキュアなアクセスを行うといったことが可能になり、
- イントラネット上の社内アプリケーションにも同様の仕組みを導入することにより、
セキュアなシングル サインオンという非常に利便性の高いシステムを構築できる。
クレームベース認証界隈のコンテキストでは、
SAMLや JWTなどのフォーマットが使用される。
IdP/STS が発行する認証・認可の情報
（認証情報やユーザーや属性、アクセス権限等の情報）。
トークンを参照。
認証連携（ID フェデレーション）で連携されるユーザ属性情報。
以下は、OAuth 2.0 / OpenID Connect における
response_type・response_mode・scope の組み合わせと、
成立するフローの対応をまとめたものである。
元データ：ClaimsBasedAuthentication_OAuth_And_OIDC.xlsx
補足（最新化）: 上表のうち、Implicit Flow （
response_type=token/id_token token等）は現在非推奨である。 OAuth 2.0 Security Best Current Practice（RFC 9700）では、 ブラウザ アプリを含むすべてのクライアントで Authorization Code Flow + PKCE（RFC 7636） を使うことが推奨されている。 また Resource Owner Password Credentials（grant_type=password）も 同様に非推奨となっている。
紛らわしい、クレームベース認証の役割関連用語の対応表をまとめてみた。
| # | SAML | WS-FED | OpenID1.0 | OpenID2.0 | OAuth1.0 | 認可の4役割 (OAuth2.0/OIDC系) |
OIDCの認証を考慮した呼称 |
|---|---|---|---|---|---|---|---|
| 1 | Subject | Subject | End User | End User | User | Resource Owner | Resource Owner |
| 2 | SP (Service Provider), RP (Relying Party) | SP (Service Provider), RP (Relying Party) | RP (Relying Party) | Consumer | OAuth Consumer | Client (Public Client, Confidential Client) | Client, RP (Relying Party) |
| 3 | IdP (Identity Provider), CP (Claim Provider) STS (Security Token Service) |
同左 | IdP (Identity Provider) | OP (OpenID Provider) | OAuth Service Provider | Authorization Server (AuthZ) | Authentication Server (AuthN)、 若しくは、IdP/STS（OP:OpenID Provider） |
| 4 | ― 認証のみなので対応する概念が存在しない ― | ― | ― | ― | ― | Resource Server | Resource Server |
- 一般向けには、SAML 系の用語が良く使われる
（IdP/STS、SP、RP 辺りは、結局 OIDC でも使われているので）。 - 最近は、OAuth2/OIDC の隆盛に伴い、上記表中の「認可の 4 役割」用語も利用される。
- 説明資料によって、上記表中の横並びの役割は混同されていることが多い（意味も同じ）。
- 「#3」は、ユーザ ストア機能とトークン発行機能に分けて表現されることがある
（IdP/STS など。CP も ≒ STS か）。
実装としては、フェデレーション サービス (AD FS)、
Microsoft Azure Active Directory、Keycloak などがある。
| プロトコル | 主な用途 | 備考 |
|---|---|---|
| SAML 2.0 | 企業間 SSO、SaaS 連携 | XML ベース。エンタープライズ SaaS での採用が多い |
| WS-Federation | Windows 系のレガシー SSO | AD FS 1.x 時代からの資産 |
| OpenID Connect | Web／モバイル／API | OAuth 2.0 の認証拡張。新規開発の第一候補 |
| OAuth 2.0 | API の認可 | 単体では認証プロトコルではない点に注意 |
補足: OAuth 2.0 を「認証」に流用する実装は、 アクセス トークンが「誰に発行されたか」を検証しないと なりすましを許す（いわゆる confused deputy 問題）。 認証が必要なら OpenID Connect の ID トークンを使う。
- 認証基盤
- アイデンティティ管理技術解説 - IPA
- RFC 9700 - Best Current Practice for OAuth 2.0 Security
- OpenID Connect Core 1.0
Tags: 認証基盤, クレームベース認証