Skip to content

MS_ASPNETCoreAuthentication

Jump to bottom
nishi_74322014 edited this page Aug 11, 2026 · 2 revisions

ASP.NET Core における 認証

概要

ASP.NET Core における 認証についてまとめた。

補足（全体像）: ASP.NET Core の認証は
「認証ハンドラ（スキーム）を登録し、どれを使うか選ぶ」という
一貫した仕組みになっている。ASP.NET（.NET Framework）の
「<authentication mode="Forms">」のような
排他的なモード指定ではない点が最大の違いである。

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie()                       // ブラウザ向け
    .AddJwtBearer("Bearer", o => {})   // API 向け
    .AddOpenIdConnect("oidc", o => {});// 外部 IdP

app.UseAuthentication();   // ← 順序が重要
app.UseAuthorization();

UseAuthentication() は UseAuthorization() より前、
かつ両方とも UseRouting() の後、MapXxx() の前に置く。
順序を誤ると「401 にならず匿名で素通りする」等の不可解な挙動になる。

詳細

CookieAuthentication

概要

MVC5（ASP.NET MVC）,
MVC6（ASP.NET Core MVC）の両方で
ASP.NET Forms認証の代替となる、
CookieAuthentication ミドルウェアを使用可能。

補足（Forms 認証との対応）: 設定項目は概ね次のように対応する。

ASP.NET Forms 認証 ASP.NET Core Cookie 認証
<forms loginUrl="..."> options.LoginPath
<forms timeout="30"> options.ExpireTimeSpan
slidingExpiration="true" options.SlidingExpiration（既定 true）
<forms name=".ASPXAUTH"> options.Cookie.Name
protection="All"（machineKey） Data Protection API（後述）
requireSSL="true" options.Cookie.SecurePolicy
（なし） options.Cookie.SameSite

鍵の扱いが根本的に違う点に注意する。
Forms 認証は machineKey を web.config に書いて共有したが、
ASP.NET Core は Data Protection API が鍵リングを管理する。

既定では鍵はローカル ディスク（またはユーザー プロファイル）に
保存されるため、Web ファーム / コンテナでは共有設定が必須である。
これを忘れると「たまにログアウトする」「再デプロイで全員ログアウト」
という症状になる。

builder.Services.AddDataProtection()
    .PersistKeysToAzureBlobStorage(blobUri, credential)   // 共有ストア
    .ProtectKeysWithAzureKeyVault(keyUri, credential)
    .SetApplicationName("MyApp");   // ← 共有するアプリで同じ名前にする

SetApplicationName は、ASP.NET でSessionCookie、Cookie認証Ticketを共有する方法
の machineKey 共有に相当する役割を持つ。

参考

ASP.NET Core Identity

  • 認証は OAuth 2.0 の IdP / STS として、アプリから分離したほうがイイ。
  • ASP.NET Core MVC 用には、ASP.NET Core Identityがある。

補足（この判断は正しい）: 「認証は分離する」という方針は、
現在ますます妥当になっている。理由は次の通り。

  • アプリが増えると認証を作り込む場所が増える（漏れが出る）
  • 条件付きアクセス・多要素・パスキーといった要件が
    アプリ側に染み出すと手に負えない
  • 監査・ログ・失効を一箇所に集められる

実装の選択肢は次の通り。

選択 向く場面
Microsoft Entra ID / Entra External ID 組織 / B2C。運用を任せられる
Keycloak / Community STS（OpenIddict 等） オンプレ・自前運用が要る
ASP.NET Core Identity を各アプリに埋め込む 単一アプリで完結する小規模系

なお、アプリ側は「OIDC の RP になる」だけにしておくと、
IdP を後から差し替えられる。

Cookie と Bearer の使い分け

補足: 実務で最も判断を要するのがここである。

対象 スキーム 理由
サーバー レンダリングの Web Cookie CSRF 対策（SameSite + アンチフォージェリ トークン）と併用
同一サイトの SPA Cookie（BFF パターン） XSS でトークンを盗まれない
ネイティブ / 別ドメインの SPA Bearer（JWT） Cookie が使えない
サーバー間 Bearer（Client Credentials） ユーザ コンテキストが無い

「SPA だから JWT を localStorage に置く」は
XSS 一発で全部盗まれるため、現在は推奨されない。
同一サイトなら BFF（Backend for Frontend）で Cookie に閉じ込める
のが OAuth 2.0 for Browser-Based Apps の推奨である。

複数スキームを併存させる場合は、
エンドポイントごとに使うスキームを明示する。

[Authorize(AuthenticationSchemes = "Bearer")]
public class ApiController : ControllerBase { }

参考

Tags: 移行, プログラミング, .NET開発, .NET Core, ASP.NET, ASP.NET MVC, 認証基盤

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

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally