Skip to content

MS_ASPNETIdentityCommunitySTS

nishi_74322014 edited this page Aug 11, 2026 · 2 revisions

ASP.NET Identity の Community STS

概要

Community STS というのは、≒ OSS の STS Middleware と言う事。

.NET Framework(ASP.NET Identity

OAuthAuthorizationServerMiddlewareを使用する。

.NET Core(ASP.NET Core Identity

.NET Core では、OSS の STS Middleware がリリースされている。

ASOSとOpenIddict

ASOS = AspNet.Security.OpenIdConnect.Server

  • Apache License 2.0
  • OpenID Connect に対応している。
  • OpenIddict は、ASOS をベースに使用している。
    (ASOS を単独利用という話もあってイイのかもしれないが…。)

補足(最新化): ASOS は 2020 年に開発を終了し、
OpenIddict 3.0 に統合された
(作者は同じ Kévin Chalet)。
現在 ASOS を新規に選ぶ理由はない。

OpenIddict の現状(.NET 8 / 9 世代)は次の通り。

項目 内容
ライセンス Apache 2.0(無償
認定 OpenID Foundation の認定実装
対応 OIDC / OAuth 2.1 / PKCE / Device Flow / Introspection / Revocation
ストア EF Core / MongoDB。抽象化されており差し替え可能
位置づけ .NET で自前ホストする STS の第一候補

ASP.NET Core Identity との統合も想定されており、
「ユーザ管理は Identity、トークン発行は OpenIddict」
という組み合わせが標準的である。

IdentityServer4

  • .NET Foundation の一部
  • Apache License 2.0
  • OpenID Connect - FAPI Part 1(MS_FAPIPart1.md)までサポート。

補足(最新化:重要な変更): IdentityServer4 は 2022 年 11 月に
サポートを終了
し、後継は Duende IdentityServer となった。
このときライセンスが商用(RLM: Reciprocal Public License /
有償ライセンス)に変更
されている。

IdentityServer4 Duende IdentityServer
ライセンス Apache 2.0 商用(一定の売上規模未満は無償枠あり)
サポート 終了(2022-11) 現行
.NET Foundation 所属していた 離脱

既存システムで IdentityServer4 を使っている場合、
セキュリティ修正が提供されていない
点に注意が要る。
移行先は Duende(有償)または OpenIddict(無償)になる。

これは「OSS だから安心」ではないことを示す実例であり、
本ページ末尾の「自作と比較」の議論とも直結する。

その他

Cierge

Gluu

補足(現在の主な選択肢): 上記に加え、
.NET に限らず実務でよく選ばれるのは次である。

製品 特徴
Keycloak Java 製 / CNCF。機能豊富、Docker で即起動。実績が最も多い
Authentik Python 製。UI が現代的
Ory Hydra Go 製。OAuth2/OIDC に特化(ユーザ管理は別)
Microsoft Entra External ID マネージド。B2C の後継

「自前ホストの運用負荷(鍵管理・可用性・脆弱性対応)」を
引き受けられないなら、マネージドを選ぶのが最も安全である。

自作と比較

高品質なプロダクトを作成する場合、
技術的 STP(DNET_STPMarketing.md)で設計ディシジョンに対する
意思決定をすべきと考える。

利用

OAuthAuthorizationServerMiddlewareの利用で感じたこと。

メリット

  • OAuth 2.0(RFC)自体を知らないところから
    ガイドされながら利用フェーズに入れる。

  • その後、理解を深めるために、RFC を読む等する必要が出てくる。

  • 拡張の実装にパワーを割く必要がない。

    • バージョンアップで取り込まれる。
    • ただし、勝手に新機能が取り込まれるのでもないので、
      拡張の仕様ぐらいは抑えて実装する必要がある。

    ※ 実際は、OAuthAuthorizationServerMiddlewareは、
     利用始めからメンテナンス・フェーズだったので、
     バージョンアップで拡張実装が取り込まれたことはない。

デメリット

  • 「補助輪 不可避」問題に遭遇する可能性。

    • id_token が挿入できない。
    • 拡張の grant_type がエラーになる。
  • 結局かなり深い所まで見る必要がある。

    • データストア(運用 / クラスタリング / EF キャンセル)
    • 証明書や JWK の取り回し(ローリング / Windows ⇔ Linux)
  • OAuthAuthorizationServerMiddlewareは、
    メンテナンス・フェーズになったため、

    • 拡張は、以下のような魔改造で対応した。
      • HTTP Module を使用した、HTTP Response の書換
      • OAuth 2.0 拡張用の Token エンドポイント追加
    • また、その後の度重なる、OAuth 2.0 拡張に対応するため、
      RFC を読んで追加実装をして行った。

自作

メリット

以下の点でメリットがある。

  • 先ず、以下の問題に遭遇しない。

    • 「補助輪 不可避」問題
    • discon(or メンテナンス・フェーズ)
  • RFC の理解、実装の理解が十分にできるため、

    • 運用フェーズに入ってからの問題に遭遇し難い。
    • Client 側実装の負荷が増えつつあるが、
      Server 実装を理解している方がサクサク書ける。
  • その他、自作メリットと言うか、根拠的なモノ。

    • 認証はウワモノ臭がキツイ感がある。
    • ウワモノ知識だけでは取り回しが難しい。
    • 自作物件はフレームワークではなくライブラリ&テンプレートになる。
      • フレームワークとは設計思想が違う。
      • .NET Framework(MS_DotNetFramework.md)、
        .NET Coreの両方をサポートできる。
    • 魔改造で、資産が溜まっているので、新規実装はあまり負担にならない。

デメリット

  • 自作は大変と言えば大変。
  • 貢献しろという話もある。

補足(この議論をどう受け取るか): 本ページの主張は
中途半端に依存すると、結局中身を全部理解する羽目になる。
ならば最初から理解して自作する方が見通しが良い
」というもので、
実体験に基づく説得力がある。
実際、IdentityServer4 のライセンス変更・サポート終了は
「discon(or メンテナンス・フェーズ)に遭遇しない」という
自作のメリットを裏づける形になった。

ただし、自作を選ぶ場合に引き受けることになるものは明確にしておきたい。

項目 自作で自分が負う責任
RFC 追従 OAuth 2.1 / RFC 9700 / FAPI などの更新を読み続ける
鍵の運用 生成・保管・ローテーションjwks_uri 公開
脆弱性対応 自分で見つけて自分で直す(第三者の目がない)
相互運用性 認定テストが無い。相手の実装ごとに検証が要る
属人化 実装者が離れたら誰も触れない

判断の目安としては、

  • 認証そのものが製品価値(IdP を作っている)→ 自作もあり
  • 業務システムの一部→ 既製品・マネージドに寄せる

という切り分けが実務的である。
技術文書中での Shall / Should / May」で
触れられている通り、仕様の解釈幅が大きい領域なので、
認定実装(OpenIddict など)を使う価値は小さくない

参考

ASOSとOpenIddict

IdentityServer4 / Duende IdentityServer


Tags: 移行, .NET開発, .NET Core, ASP.NET, ASP.NET MVC, ASP.NET Identity, 認証基盤, セキュリティ

NetDevInfraWiki

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

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally