OpenID

OpenID（オープンアイディー（））は分権的な認証プロトコルのオープンスタンダードで、非営利団体のOpenID財団が標準を策定している。名称は同団体の登録商標である^[1]。

ロゴ

OpenID財団は、誰でも参加可能な手順「OpenID Process」を経て、デジタルアイデンティティ関連の標準化を行っている。2007年には、OpenID 2.0を発表。2014年2月、OpenID Connect(OIDC)の最終仕様を承認^[2]。OpenID 2.0は実質的なレガシーとなり、OpenID Connect(OIDC)が最新の仕様である^[3]。本記事では、OpenID財団とOpenID財団が策定した仕様について記述する。

OpenID 1.0/1.1

OpenIDの最初のバージョンであるOpenID 1.0は、2005年5月にLiveJournalの開発者であるブラッド・フィッツパトリックによって考案された。当初はLiveJournal内での利用を想定していたが、Yadisなどの技術を取り込みながら、ブログやWebサイト間での分散型認証としてコミュニティ主導で仕様が整備された。セキュリティ上の脆弱性や仕様の曖昧さが指摘され、後続のOpenID 2.0が登場したことで、その役割を終えた。主要なライブラリやサービスでのサポートは既に行われていない。

OpenID 2.0

→詳細は「OpenID Authentication 2.0」を参照

2007年12月に設立されたOpenID財団によって正式に策定された規格である。OpenID Authentication 2.0ともいう。

ユーザを識別するには、URIベースの主張識別子^[4]を用いる。これは、ユーザが入力したものではなく、認証サーバが割り当てた再利用されないURIである。その為、ユーザ識別子の使い回しによる、旧ユーザのアカウントを新ユーザがのっとってしまう ユーザー・インパーソネイション^[5] と呼ばれる問題が解決されるなどの特徴を持っている。

また、OpenID Simple Registration Extension、OpenID Attribute Exchange などの拡張仕様を利用することによって、ユーザの属性情報を連携することができる他、どのような本人確認や認証手段（パスワード、OTP、ICカードなど）を使ったかなどの認証コンテキスト^[6]も同時に連携可能である。

Google、Yahoo!、mixiなどの大手プラットフォーマーがアイデンティティプロバイダ（IdP）として参入したことで広く普及した。単に「OpenID」と言った場合、かつてはこのバージョンを指すことが多かった。

OpenID 2.0は、URLをユーザーIDとして入力させる仕組みであった。このため、ユーザーにとって使いづらく、フィッシング詐欺などセキュリティリスクが高い仕様であった。また、データ形式に複雑なXMLや独自署名を用いていたため、RESTful APIやJSONが主流となるWeb開発のトレンドやスマートフォンアプリとの親和性が低かった。

これらを理由に、OAuth 2.0ベースの次世代規格への移行が進められた。 2014年2月、OpenID Connect(OIDC)の最終仕様を承認^[2]。OpenID 2.0は実質的なレガシーとなった。その後、2015年4月、GoogleがOpenID 2.0のサポートを完全に終了し、OpenID Connectへの移行を完了した^[7]。 2017年10月、Yahoo! JAPANがOpenID 2.0による認証提供を終了した^[8]。現在は非推奨（Deprecated）であり、主要サービスでのサポートは終了している^[9]。

OpenID Connect

→詳細は「OAuth」を参照

上記のOpenID 2.0の弱点や、認可基盤であるOAuthでID連携をカスタム実装するという非推奨の実装が氾濫していた現状を踏まえ、OAuth2.0をベースにした、新たな認証基盤が求められていた。

2014年2月、OpenID Connect(OIDC)の最終仕様が承認^[2]された。OpenID ConnectはOAuth2.0を拡張し、「IDトークン（ID Token）」という概念を導入することで、標準化された手順での認証を実現したものである。これにより、GoogleやApple、MicrosoftなどのIDを使用して、第三者のアプリケーションにログインするSSOが安全かつ容易に実装可能となった。

ロール

OpenID Connectは、以下の3つのロールによって構成される^[10]。

• エンドユーザー - 本人確認される対象の人間
• リライイング・パーティ (RP) - 認証を要求するクライアントアプリケーション
• OpenIDプロバイダ (OP) - エンドユーザーの認証を行い、RPに対して認証結果とユーザー情報を提供する認可サーバー

IDトークン

IDトークンは、JSON Web Token(JWT) 形式で記述されたセキュリティトークンである。RPはこのトークンを検証することで、ユーザーがOP側で正しく認証されたことを確認できる。IDトークンには「クレーム（Claims）」と呼ばれる以下のような情報が含まれる。

• iss (Issuer) - トークンの発行者であるOPのURL
• sub (Subject) - ユーザーを一意に識別するID
• aud (Audience) - トークンの利用対象者であるRPのクライアントID
• exp (Expiration Time) - 有効期限
• iat (Issued At) - 発行日時
• nonce - リプレイ攻撃を防ぐためのランダムな文字列

UserInfo エンドポイント

RPは、アクセストークンを使用してOPが提供する「UserInfo エンドポイント」にアクセスすることで、ユーザーの追加情報（氏名、メールアドレス、プロフィール画像など）を取得することができる。これらは標準化されたスコープ（openid, profile, email など）に基づいて提供される^[10]。

認証フロー

1. 認証リクエスト - RP（アプリ）は、ユーザーをOP（認証サーバー）の認証画面へリダイレクトさせる。この際、スコープに openid を含めることが必須である^[10]。
2. ユーザー認証 - ユーザーはOPの画面でログインし、RPへの情報提供を許可する。
3. 認可コードの発行 - OPはユーザーをRPへリダイレクトさせ、その際に「認可コード」を付与する。
4. トークンリクエスト - RPは認可コードをOPのトークンエンドポイントへ送信する。
5. トークンの取得: OPはコードを検証し、IDトークンとアクセストークンをRPへ発行する。
6. IDトークンの検証 - RPはIDトークンの署名を検証し、改竄されていないこと、および自サービス向けに発行されたものであることを確認する。
7. ログイン完了 - 検証が成功すれば、RPはユーザーをログイン状態として扱う。必要に応じてアクセストークンを用いてUserInfoエンドポイントから詳細情報を取得する。

セキュリティ上の考慮事項

OpenID Connectの実装においては、なりすましやリプレイ攻撃を防ぐため、以下の対策が仕様に組み込まれている。

• IDトークンはOPの秘密鍵で署名されており、RPはOPの公開鍵を用いてこれを署名検証しなければならない。
• リクエスト時に、Nonceと呼ばれる生成したランダムな文字列が、返却されたIDトークンに含まれているかを確認し、リプレイ攻撃を防ぐ。
• URLに付与されているstateパラメータと、アクセスしてきたユーザーのセッションに格納されているstateパラメータを比較して、一致していなければ不正なアクセスとして、処理を中断する。これは、CSRF攻撃を防ぐために使用される^[11]。

OpenID財団

米国オレゴン州で設立された、501(c)(6) 非営利団体である。著作権管理、商標管理、仕様をライセンス費用無しに使うことができるようにする（制限付き特許権非行使ライセンス）ための標準化プロセスの管理、OpenID財団の標準化プロセスで標準化された各種規格についての普及啓蒙を行うことを使命としている。

特許権管理は、「制限付き特許権非行使ライセンス」と呼ばれるモデルで、OpenID財団標準仕様の実装に対して、不可逆的特許権非行使宣言を行った主体に対しては特許権を互いに行使しないというものになっている。OpenID財団標準を実装したある企業が、他の企業に対して特許権の主張を行った場合、他の特許権保持者は当該企業に対しては特許権の行使ができるようになる。このため、特許権の行使には抑制的に働き、結果的に通常のロイヤリティ・フリーモデルよりも安全に利用できるようになることを狙っている。

OpenID Process

OpenID Process Document^[12]によって規定される標準化プロセス。概ね以下の経緯をとって仕様として標準化される。

1. ワーキンググループ設置提案（設立趣意書提出）
2. 仕様カウンシルによるレビュー
3. 理事会によるレビュー
4. ワーキンググループ設置
5. ワーキンググループメンバーによるIPRアグリーメント^[13]提出
6. ワーキング・ドラフト作成
7. 実装者仕様案レビュー（45日間）
8. 実装者仕様案投票（7日間）
9. 実装事例およびフィードバック収集
10. （大幅な変更が会った場合は、実証者仕様案レビューに戻る）
11. 最終仕様案レビュー（60日間）
12. 最終仕様投票（7日間）
13. 最終仕様公開

役員

役員^[14]は以下の通り。

役職	担当者
理事長	Nat Sakimura （崎村夏彦)
副理事長	Dima Postonikov（ディマ・ポストニコフ）
会計担当	Nancy Cam-Winget（ナンシー・キャム＝ウィンゲット）
書記	Marie Jordan（マリー・ジョーダン）
コミュニティ担当	George Fletcher（ジョージ・フレッチャー）
執行役員	Gail Hodeges（ゲイル・ホジス）

法人理事

法人理事^[15]は、各スポンサー企業（年50,000ドル）によって指定された個人であり、所属が変わると他の人に引き継がれる。

スポンサー企業	担当者	備考
Authlete	Ian Glazer
Block	Manik Surtani
Chicago Advisory Partners	Elcio Calefi
グーグル	Dirk Balfanz
KDDI	Kosuke Koiwai
マイクロソフト	Pamela Dingle
Mastercard	Adam Sommer
NRIセキュア・テクノロジーズ	Osamu Oshima
Okta	Aaron Parecki
ピング・アイデンティティー	Wesley Dunnington
Yahoo	Naveen CM

コミュニティ理事

コミュニティ理事 ^[16] は、選挙によって選ばれる。なお、コミュニティ理事は、企業を離れた個人として選ばれており、所属が変わっても継続するので、所属はあくまで参考である。

担当者	備考
John Bradley	Yubico
Michael B. Jones	Self-Issued Consulting
Nat Sakimura	NAT Consulting

コーポレート理事

コーポレート理事は、一般のメンバー企業により選出される。

担当者	備考
Atul Tulshibagwale	SGNL
Mark Verstege	Australia COmmonwealth Treasury

OpenIDファウンデーション・ジャパン

2008年2月28日OpenIDファウンデーション・ジャパンの設立が発表され、2008年10月1日OpenIDファウンデーション・ジャパンが有限責任中間法人として設立された、OpenID財団の日本支部。発起人企業は、シックス・アパート、日本ベリサイン、野村総合研究所の3社。参加企業は、ウェブ系だけでなく、銀行、保険、運輸など幅広く、2012年7月現在で42社に及ぶ^[17]。

人物

• 楠正憲（代表理事）
• 崎村夏彦（理事）
• 米谷修（理事）
• 林達也 (理事)
• 富士榮 尚寛 (理事)
• 真武信和（事務局長）