Skip to content

MS_OpenID

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

OpenID

概要

補足（最重要）: 本ページが扱う OpenID Authentication 1.1 / 2.0 は、
2014 年に OpenID Connect へ置き換えられ、
現在は使われていない。

OpenID 2.0 OpenID Connect
識別子 URL（http://example.com/user） メール等（sub は不透明な ID）
基盤 独自プロトコル（XRDS / Diffie-Hellman） OAuth 2.0 + JWT
データ形式 key-value（HTTP パラメタ） JSON
モバイル対応 弱い 前提として設計

Google は 2015 年に OpenID 2.0 のサポートを終了している。
本ページは歴史的経緯を理解するための資料として読むのが正しい。

「URL を自分の ID にする」という発想は先進的だったが、
一般ユーザーに URL を覚えさせるのは無理があり、
それが普及しなかった主因とされる。

OpenID 1.1

End Userは自分のClaimed Identifierを認証するIdPを明示。

Claimed Identifier と IdP のエンドポイント URL が同一ホストにある場合

head 要素の中に link 要素として、下記のように記載。

<link rel="openid.server" href="IdPが提供するサーバのエンドポイントURL" />

Claimed Identifier と IdP のエンドポイント URL が同一ホストにない場合

これにより、Claimed Identifier の認証を外部の IdP サーバに委ねる事ができる。

<link rel="openid.server"   href="IdPが提供するサーバのエンドポイントURL" />
<link rel="openid.delegate" href="Claimed Identifierとして使用するURL" />

Consumer サイトの OpenID ログイン・フォーム

Enter your OpenID URL なので、Claimed Identifier の URL を入力する。

ブラウザのオートコンプリートを利用するため、
OpenID URL のテキスト・フィールドは name 属性値に
openid_url と統一した名前を付けることが推奨されている。

<form id="openid_form" action="./login.cgi" method="post">
  <fieldset>
    <legend>Enter your OpenID URL</legend>
    <input type="text" id="openid_url" name="openid_url" value="" />
    <input type="submit" id="openid_url_submit" name="openid_url_submit" value="LOGIN" />
  </fieldset>
</form>

処理シーケンス

処理シーケンスを、Consumer サイト上の処理を中心に説明する。

  1. OpenID ログイン・フォームに Claimed Identifier の URL が入力される。
  2. Consumer は、openid.server と openid.delegate を参照する。
  3. 通常、smart mode を選択し、Claimed Identifier の認証手続きを行う。
  4. Consumer は End User の User-Agent に IdP に対する問い合わせを指示する（2 通り）。
    1. ユーザにリダイレクト要求（302 リダイレクト）を返し、IdP にリクエストさせる。
      これにより、IdP の認証手続きページに画面遷移しログインや情報開示可否を選択できる。
    2. Ajax スタイルの非同期通信による問い合わせ方式
  5. Consumer は End User の User-Agent が IdP から受け取った紹介状を
    リダイレクトで受け取る。
  6. dumb mode の場合、Consumer は紹介状の妥当性を直接 IdP に問い合わせる。

移行メモ: 元ページの「示指する」は「指示する」の誤りと判断して正した。

openid.mode

モード 内容 経路
associate Consumer と IdP の間で、共通鍵の共有を行う。smart mode を処理する場合に必要（失敗時は dumb mode に移行） Consumer ⇔ IdP（POST）
check_authentication 紹介状が正しいかどうか、IdP へ問い合わせる。dumb mode で必要 Consumer ⇔ IdP（GET）
checkid_immediate Claimed Identifier が Verified Identifier であるか IdP へ問い合わせる Consumer →（302）→ UA →（GET）→ IdP
checkid_setup 属性情報の通知方法を設定可能な IdP の画面が提供される 同上

smart mode と dumb mode

OpenID 認証における、大まかな動作指針

  • smart mode — 事前に Consumer と IdP の間で共通鍵を共有し、
    信頼関係を成立させておくモード。
  • dumb mode — 事前に共通鍵を共有することなく、
    Claimed Identifier の認証手続きを行う。smart mode と比べて
    一連の手続きの最後に 1 つ余計に処理が増える。

補足: この「共通鍵を共有して署名を検証する（smart）」か
「毎回 IdP に問い合わせる（dumb）」かの対比は、
現在の OAuth 2.0 のトークンにおける
「内包型（自前で署名検証）」と「識別子型（Introspection）」の
対比とまったく同じ構図である。

OpenID Simple Registration Extension 1.0

OpenID 1.1 の拡張機能で、End User の登録情報を照会する機能。

  • IdP のエンドポイント URL にリダイレクトさせる際に
    所定のクエリーパラメータを追加する。
  • 紹介状をリダイレクトで受け取る際の URL に含まれる
    クエリパラメータの一部として返ってくる。
  • 含める事ができる値 — ニックネーム / メールアドレス / フルネーム / 誕生日 /
    性別 / 郵便番号 / 国 / 言語 / タイムゾーン
  • Consumer は照会したい項目を選択できる。End User は照会要求を拒否できる。

補足: これが OpenID Connect の
scope（profile / email / address / phone）と
UserInfo エンドポイントに相当する。
「必要な属性だけを、同意のうえで受け取る」という考え方は
この時代から一貫している。

セキュリティ

難しい。

以下の 3 つがある。

通信経路のセキュリティ

  • smart mode で、Consumer ⇔ IdP 間で共通鍵を共有する。
    • Diffie-Hellman 鍵共有（または鍵交換）プロトコルを使用する。
    • 以降、HMAC-SHA1（ハッシュ関数と秘密鍵）の署名でメッセージ改ざんを防止。
  • メッセージ署名（id_res モード = IdP から返される紹介状）

セキュリティ上の脅威

  • フィッシング（悪意のある Consumer サイトからニセの IdP に誘導）
  • OpenID Realm Spoofing（より、狡猾なフィッシング）
  • Google 検索などを用いてアカウント名の収集が可能。
  • 紹介状の送信に対するリプレイ攻撃が可能。
    Consumer 側で、nonce（ワンタイムな値）を追加する。

補足（致命的だった弱点）: フィッシング耐性の低さが
OpenID 2.0 の構造的な問題だった。
ユーザーが RP に「自分の IdP の URL」を入力する仕様上、
悪意ある RP が偽の IdP ログイン画面を出せば、ほぼ見分けられない。

現在の OpenID Connect では
RP を事前登録し、redirect_uri を完全一致で検証することで
この経路を塞いでいる。
さらに根本的な対策が FIDO / パスキーである
（Origin に束縛されるため、偽サイトでは署名が作れない）。

OpenID 2.0

  • 一般ユーザーがより使いやすい仕様（Identifier / 認証方式）。

Identifier の記述形式

  • URL のほかに、XRI という URI を拡張した形式で記述できる。
  • XRI は従来の URL と比べて短い文字列を使用できる。
  • XRI はドメインのように取得する必要がある。
  • xri:// → http://xri.net/ と変更すると、
    xri.net の XRI Proxy Resolver が XRI 文字列を解釈して適切なリソースを返す。

User-Supplied Identifier

  • RP はエンドユーザーにログインフォームを表示する。
  • Claimed Identifier を RP のログインフォームに入力して認証する。

変更点

  • 1.1 の場合では Claimed Identifier を入力。
  • 2.0 では User-Supplied Identifier を入力。
    • 従来どおりに Claimed Identifier を入力して認証
    • OP で使用したい Identifier を選択し OP Identifier を入力して認証
      → ユーザーは自分の長い Claimed Identifier を覚える必要がなくなる。
  • User-Supplied Identifier とは、Claimed Identifier または OP Identifier の総称。

XRDS ベースの discovery

XRDS という XML のフォーマットは以下が可能。

  • サービスに対応している認証サービス（OP）の詳細を指定

    • サービスの優先順位を指定 / エンドポイント URL を指定

  • OpenID 2.0 ベースでの delegate 設定サンプル

<head>
  <link rel="openid.server"    href="OpenID 1.1のIdPが提供するサーバのエンドポイントURL" />
  <link rel="openid.delegate"  href="OpenID 1.1のClaimed Identifierとして使用するURL" />
  <link rel="openid2.local_id" href="OpenID 2.0のOP-Local Identifier URL" />
  <link rel="openid2.provider" href="OpenID 2.0のOPのエンドポイントURL" />
  <meta http-equiv="x-xrds-location" content="XRDS文書のURL" />
</head>

OP-Local Identifier：OP 上でのユーザ ID

補足: この XRDS による discovery が、
OpenID Connect の
**/.well-known/openid-configuration（Discovery）**に相当する。
HTML に link タグを埋める方式から、
JSON を既知の URL で返す方式へ簡素化された。

参考

  • OpenIDの仕様と技術 連載インデックス - ＠IT
    http://www.atmarkit.co.jp/fsecurity/index/index_openid.html

    • （2）あなたのサイトをOpenID対応にしている2行の意味
    • （3）Consumerの実装を知り、OpenIDを使ってみよう
    • （4）OpenIDをとりまくセキュリティ上の脅威とその対策
    • （5）OpenID Authentication 2.0時代の幕開け

  • OpenID Foundation
    https://openid.net/

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

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

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally