Skip to content

MS_OAuthOIDCProblemSolving

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

OAuth / OpenID Connectによる課題解決

概要

  • OAuth / OpenID Connectの
    課題解決ノウハウをまとめています。

  • 説明を始めると、

    「単に「ユーザストアを使ってアプリを認証する。」ということではない。」

    というトコロからの説明が必要になります。

導入

要件の確認

SSO（Single Sign-On）をサポートする。

認証 / 認可フレームワークをサポートする。

  • 認証 / 認可フレームワークとはなにか？
  • このフレームワーク中で下記「4 つの登場人物」はどのようなロールを担うか？

（Web）API エコノミーをサポートする。

システム間を連携させる API (Application Programming Interface) を通じて、
既存のサービスやデータをつなぎ、新たなビジネスや価値を生み出す仕組み。

移行メモ（誤字）: 元ページの「Application Programing Interface」は
「Programming」、「システム間連系」は「システム間連携」の誤りと解して
修正した。

ID 連携、ID フェデレーション、Federated identity をサポートする。

  • 認証用のユーザストアと属性格納用のユーザストアを分離できる。

  • これにより、認証基盤の、

    • セキュリティ・レベル
    • IT ガバナンス

    を維持しつつ、アプリケーション、サービス側で、柔軟な対応をとることができる。

4 つの登場人物

「OAuth2 の 4 つの登場人物」についての説明が必要。

Resource Owner

認証 / 認可を行うユーザー

  • 下記「Authorization Server」にサインインすることで認証される。
  • 下記「Client」が要求する認可を Authorization Server 上で
    許可することで token が発行される。

Authorization Server

認証 / 認可の根幹となる機能を提供するプログラム。

  • IdP と STS から構成される。

    • IdP

      • Identity Provider
      • サインアップ、サインイン・サインアウトの機能を提供。

    • STS

      • Security Token Service
      • サインイン（認証）したユーザ（Resource Owner）と
        認可された範囲を示す token を発行する。

Resource Server

Authorization Server に対応した WebAPI を提供するプログラム。

  • 認証されたユーザ（Resource Owner）に、認可された範囲の処理・データを提供する。

Client

Authorization Server を使用して Resource Server の WebAPI に
アクセスするプログラム。

  • Client が、Authorization Server に token を要求すると、
    ユーザ（Resource Owner）がサインイン（認証）・認可した token を受け取る。

  • Client は、この token を使用して、Resource Server の WebAPI にアクセスする。

補足（IdP と STS を分けて考える意味）: この「IdP ＋ STS」という
分け方は、本ページの後段（「STS により、独自ユーザストアから
全社認証基盤へ。」）の議論に直結する重要な整理である。

  • IdP は「誰であるか」を確かめる部分（ユーザストア・ログイン画面）
  • STS は「確かめた結果をトークンにして配る」部分

既存システムが持っているのは大抵 IdP 相当だけなので、
STS を足せば、ユーザストアを移さずに SSO 基盤にできる
というのが本ページの主張の核である。
なお OpenID Connectの用語では、
この 2 つを合わせて OP（OpenID Provider） と呼ぶ。

適切なフローの選択

ベース クライアント セキュリティ モデル（基本）

サーバ信頼セキュリティ モデル（例外）

スマホの場合

補足（現在のフロー選択）: 「疑似 PKCE」という記述は、IdP が
PKCE 未対応だった当時の回避策である。
現在は主要な IdP がすべて PKCE に対応しており、
OAuth 2.1 では全クライアントで PKCE 必須なので、
迷う場面は無くなった。
選択の指針は
OAuth 2.0 Threat Model (Flow)の表を参照。

よくある誤解

Cookie 認証チケットと AccessToken の違い

  • Cookie 認証チケット

    • ログインは通常、Cookie 認証チケットによって形成される
      「ログイン・セッション」に依存する。
    • 以下の 2 つの「ログイン・セッション」を別々に認識する必要がある。
      • Authorization Server 側の Cookie 認証チケットによるログイン・セッション
      • Client 側の Cookie 認証チケットによるログイン・セッション

  • AccessToken
    AccessToken はあくまで、

    • IdP で認証できたという結果をうけて
    • STS が生成・通知する token なので、

    上記の 2 つの Cookie 認証チケットとは別物になる。

補足（この 3 つを混同すると設計が壊れる）: ここは実務で最も
事故が多い箇所である。3 つのライフサイクルは独立している。

主体 実体 切れたときに起きること
Authorization Server のセッション IdP の Cookie 再ログイン画面が出る
Client のセッション アプリの Cookie アプリからログアウトされる
AccessToken Bearer トークン API 呼び出しが 401 になる

「IdP でログアウトしたのにアプリに入れたままになる」という
よくある問題は、この独立性が原因である
（OpenID Connectの
ログアウト系仕様は、これを揃えるためのもの）。

パッケージに、IdP/STS を組み込んだら上手くいく。

  • OSS コンソーシアム

    • OAuth2 / OpenID Connect 課題解決 備忘録 5（2018/06/18 予定）
      https://www.osscons.jp/joq7suwpb-537/

      パッケージに IdP/STS を組み込もうとしてしまう現象について。

詳細

そもそも認証から（IdP 単品）

IdP の機能をフルサポートするのは大変

ASP.NET Identityが参考になる。

STS により、独自ユーザストアから全社認証基盤へ。

  • システムやパッケージに独自ユーザストアを持つのは、
    非効率、且つ、セキュリティ的にも脆弱になり易いという問題を持つ。

  • IdP に、OAuth / OpenID Connectなどの
    STS 機能を搭載すれば、
    SSO（Single Sign-On）によって、この問題を解決できる。

クロスプラットフォーム & コンパチブル

  • オープンなプロトコルを使用しているため、
    クロスプラットフォーム対応可能であること。

  • 故に、4 つの登場人物がプラットフォームや言語に依存せず、
    クロスプラットフォーム & コンパチブルであることが求められる。

Authorization Server からの視点

Authorization Server 提供者は、

  • 様々なユーザストアに対応する必要がある。
  • OAuth 2.0 の Bearer Token の JWT 化が必要。
  • OAuth 2.0 拡張 /
    OpenID Connectのサポートについて検討が必要。

Resource Server からの視点

Resource Server 提供者は、

  • 様々な Authorization Server と連携可能な提案を行う必要がある。

  • 従って、Token の検証方法を検討する必要がある

  • 上記 2 つをまとめて解決する、API Gatewayの導入を
    検討しても良い。

補足（検証方式の使い分け）: 「署名検証」と「Introspection」は
排他ではなく、トークンの形式で決まる。

  • JWT（自己完結型） → 署名検証。
    ネットワーク往復が無く速いが、
    即時失効ができない（有効期限まで有効）。
  • 不透明トークン → Introspection。
    毎回 Authorization Server に問い合わせるので失効が即座に効くが、
    遅く、Authorization Server が単一障害点になる。

実務では アクセストークンは短命な JWT、
refresh_token は不透明トークンという組み合わせが多い。

Client からの視点

Client 提供者は、

  • 使用する Authorization Server、Resource Server を選択する。
  • この場合、サポートされる Flow や Token のフォーマットを理解する必要がある。

ID フェデレーションの段階

以下の、3 つの段階がある。

移行メモ（未記述）: 元ページには「3 つの段階がある」とあるが、
実際に記述されているのは「Single」「Hybrid」の 2 つだけで、
3 つ目（おそらく複数 IdP を並列に扱う段階）は書かれていない。
原文のまま残す。

Single

Client ←--- IdP (Authorization Server)

  • IdP のみユーザストアを持つ。
    Client は、

    • 認証結果の Claim を Authorization Server から受け取り、
    • 認証済みの処理を行う。

  • IdP と Client がユーザストアを持つ。
    Client は、

    • 認証結果の Claim を Authorization Server から受け取り、
    • Claim をユーザストアに格納し、
    • そこに補足的ユーザ属性を加え、
    • 認証済みの処理を行う。

Hybrid

Hybrid-IdP (Client ←--- IdP2 ←--- IdP1)

  • IdP1 と IdP2 がユーザストアを持つ。
    Client から要求を受けた、Authorization Server1 は、

    • 認証結果の Claim を Authorization Server2 から受け取り、
    • Claim を Authorization Server1 のユーザストアに格納し、
    • そこに補足的ユーザ属性を加え、
    • 次いで、要求元の Client に、認証結果の Claim を返す。
    • 最後に、Client は、認証済みの処理を行う。

  • Client と IdP1 と IdP2 がユーザストアを持つ。
    Client から要求を受けた、Authorization Server1 は、

    • 認証結果の Claim を Authorization Server2 から受け取り、
    • Claim を Authorization Server1 のユーザストアに格納し、
    • そこに補足的ユーザ属性を加え、
    • 次いで、要求元の Client に、認証結果の Claim を返す。
    • Client は
      • Claim をユーザストアに格納し、
      • そこに補足的ユーザ属性を加え、
      • 認証済みの処理を行う。

※ 認証は Authorization Server2 で、属性編集は Authorization Server1 で可能。

補足（Hybrid は「IdP プロキシ」）: ここで言う Hybrid-IdP は、
自身が RP でもあり OP でもある中継役（IdP Proxy / Broker）である。
Azure AD B2C や Keycloak の Identity Brokering がこの形にあたり、
「認証は外部 IdP、属性は自前」という要件で使われる。
なお、この構成では
OAuth 2.0 Threat Model (Access)で触れた
ミックスアップ攻撃（どの IdP から戻ったかの取り違え）が
現実的なリスクになるため、iss パラメタの検証が要る。

@.NET

ASP.NET Identity（2 系）の生の実装ダケではダメ

ASP.NET Identity（2 系）を使うダケで頑張れるか？と
言えばそんなこともありません。

カスタマイズ

ASP.NET Identity（2 系）を覚えるダケでも、
ある程度、大変ですが、
更に、IdP & STS は、カスタマイズが必要となるケースが多い。

Bearer Token

  • また、ASP.NET Identity（2 系）の Bearer Token は、
    ASP.NET Identityしか理解しないので、
  • 他のプラットフォームや言語で処理可能なように
    JWT 化が必要になってくる。

プロトコル

  • 生の ASP.NET Identity（2 系）は、
    OAuth 2.0 拡張 /
    OpenID Connectをサポートしない。
  • このため、既定の実装では、より安全な認証 / 認可や、
    スマホ・ネイティブへの露出ができない。

ASP.NET Core Identity（3 系）版では、脱 Community STS した。

概要

ASP.NET Core Identity（3 系）版の汎用認証サイトでは、
諸事情により、脱 Community STS した。

参考

参考

説明に使用した図

説明しながら伝導活動の重要性を感じた次第です。

OAuth / OpenID Connectによる課題解決

OSSC > 開発基盤部会 Blog

課題解決

備忘録

個別テーマ

その他

本 Wiki 内

Tags: IT国際標準, 認証基盤, クレームベース認証, OAuth

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

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally