OAuth 2.0／OpenID Connectによる中央集権的ID管理【DID基礎 前編】

おはようございます。
web3リサーチャーのmitsuiです。

毎週土日のお昼にはweb3の基礎の基礎レポートを更新しています。今週は「ID」について解説します。ぜひ最後までご覧ください！

はじめに

スマートフォンでアプリをダウンロードして起動すると、「Googleアカウントでログイン」や「Facebookアカウントでログイン」というボタンを見かけることが多いでしょう。ワンタップでログインできて便利ですが、これらの背景にはどのような技術が使われているのでしょうか。

また、写真加工アプリを使うときに「この アプリがあなたの写真にアクセスすることを許可しますか？」といった画面が表示されることもあります。なぜこのような確認が必要なのでしょうか。

これらすべての背景にあるのが、今回ご紹介する OAuth 2.0 と OpenID Connect（OIDC） という技術です。現代のインターネット上で、私たちが安全かつ便利にさまざまなサービスを利用できるのは、これらの技術があってこそなのです。

本記事は前編として、これらの技術がどのような仕組みで動いているのか、なぜ必要なのか、そしてどのようなメリットや課題があるのかを、できるだけわかりやすく解説していきます。

1. まずは身近な例から理解しよう

技術的な話に入る前に、まず身近な例でイメージを掴んでみましょう。

ホテルのルームキーで考える認証と認可

あなたがホテルに宿泊するとき、まずフロントでチェックインの手続きをします。身分証明書を提示し、宿泊者であることを証明する。これが 「認証」 です。そして、フロントスタッフがあなたに部屋のカードキーを渡してくれます。このカードキーがあれば、あなたは自分の部屋に入ることができますが、他の人の部屋や従業員エリアには入れません。これが 「認可」 です。

デジタルの世界でも、まったく同じことが起こっています。ウェブサイトやアプリにログインするとき、まず「あなたは誰ですか？」を確認する認証が行われ、その後「あなたに何をする権限を与えますか？」という認可が決定されます。

図書館の利用券システムで考える権限管理

もう一つの例として、図書館のシステムを考えてみましょう。図書館では、利用者カードを発行してもらうことで、本を借りたり、コピー機を使ったり、学習室を予約したりできます。しかし、すべての利用者が同じ権限を持っているわけではありません。

一般利用者は本の貸し出しのみ、学生なら学習室の予約も可能、研究者なら特別資料室へのアクセスも許可される、といったように、利用者の種類によって異なる権限が与えられます。これがまさに、デジタルサービスにおける権限管理の考え方なのです。

2. 認証と認可の違いを理解する

ここで、OAuth 2.0を理解する上で最も重要な概念である「認証」と「認可」の違いをしっかりと理解しておきましょう。

認証（Authentication）とは

認証とは、「あなたは誰ですか？」という問いに答えるプロセスです。日常生活でも、私たちは様々な場面で身元確認を求められます。

銀行ATMを使うときには、カードを挿入してPINコードを入力します。これにより、銀行はあなたが正当な口座所有者であることを確認します。スマートフォンのロックを解除するときには、指紋や顔認証、あるいはパスコードを使います。これらはすべて「あなたが本当にその端末の所有者なのか」を確認する認証プロセスです。

ウェブサービスでも同様で、ユーザー名とパスワードを入力したり、二段階認証でワンタイムパスワードを入力したりすることで、サービス提供者はユーザーの身元を確認します。

認可（Authorization）とは

一方、認可とは「あなたに何をする権限を与えますか？」という問いに答えるプロセスです。これも日常生活の例で考えてみましょう。

会社では、社員証で建物に入ることができますが、すべての社員が同じフロアやすべての部屋にアクセスできるわけではありません。営業部の社員は営業フロアには入れるけれど、開発部のサーバールームには入れない。管理職なら重要な会議室も利用できるけれど、一般社員は利用できない。このように、身元が確認された後で、その人にどのような権限を与えるかを決定するのが認可です。

デジタルサービスでは、写真アプリがあなたのスマートフォンの写真フォルダにアクセスしたいとき、「このアプリに写真へのアクセスを許可しますか？」という確認画面が表示されます。あなたが「許可」をタップすることで、そのアプリは写真を見ることができるようになります。しかし、連絡先や位置情報には引き続きアクセスできません。これが認可の仕組みです。

OAuth 2.0は主にこの「認可」を扱う技術であり、OpenID Connectは「認証」機能を追加した拡張技術という関係になっています。

3. なぜOAuth 2.0が生まれたのか

OAuth 2.0の必要性を理解するために、少し歴史を振り返ってみましょう。

インターネット黎明期の問題

2000年代前半まで、ウェブサービス同士の連携はそれほど一般的ではありませんでした。各サービスは独立して運営されており、ユーザーは個別にアカウントを作成し、個別にログインして利用していました。

しかし、2000年代後半になると、状況が大きく変化します。TwitterがAPI（Application Programming Interface）を公開し、外部の開発者が Twitter のデータを使ったアプリケーションを作れるようになりました。Google Maps API、Facebook API なども次々と公開され、異なるサービス同士を組み合わせた新しいアプリケーションが数多く登場するようになったのです。

深刻な安全性の問題

ところが、この時代のAPI連携には重大な問題がありました。第三者のアプリケーションがTwitterのデータにアクセスするためには、ユーザーが自分のTwitterのユーザー名とパスワードを直接そのアプリケーションに教える必要があったのです。

これは非常に危険でした。なぜなら、そのアプリケーションがユーザーのパスワードを知ってしまうということは、そのアプリケーションがユーザーになりすまして何でもできてしまうということだからです。悪意のあるアプリケーションなら、勝手にツイートを投稿したり、アカウントの設定を変更したり、最悪の場合はパスワードを変更してアカウントを乗っ取ったりすることも可能でした。

さらに、ユーザーはそのアプリケーションに「写真を見るだけの権限」を与えたいと思っていても、パスワードを教えてしまうと「アカウントに対するすべての権限」を与えることになってしまいます。これは明らかに過剰な権限付与でした。

OAuth 2.0による革新的な解決

この問題を解決するために開発されたのがOAuth 2.0です。OAuth 2.0では、パスワードを第三者アプリケーションに渡すのではなく、「アクセストークン」という特別な鍵を発行する仕組みを導入しました。

このアクセストークンには、いくつかの優れた特徴があります。まず、有効期限があるため、永続的に悪用される心配がありません。また、特定の機能や データに対してのみ有効な限定的な権限を設定できます。さらに、ユーザーはいつでもそのトークンを無効にして、アプリケーションのアクセス権限を取り消すことができます。

OAuth 2.0は2012年にRFC 6749として正式に標準化され、現在では Google、Facebook、Microsoft、Twitter など、主要なウェブサービスのほとんどが採用しています。

4. OAuth 2.0の登場人物を理解する

OAuth 2.0の仕組みを理解するためには、まず「誰が」「何の役割を果たすのか」を明確にする必要があります。OAuth 2.0では、4つの重要な役割が定義されています。

Resource Owner（リソース所有者）

Resource Ownerは、データの所有者です。多くの場合、これはサービスを利用する一般ユーザーのことを指します。

たとえば、あなたがInstagramで写真を投稿していたとしましょう。その写真データの所有者はあなたです。別の写真編集アプリがあなたのInstagramの写真にアクセスしたいと思ったとき、その許可を出すかどうかを決める権限を持っているのがあなた、つまりResource Ownerです。

Resource Ownerは、自分のデータに誰がアクセスできるか、どのような操作を許可するかを決定する権限を持っています。これは非常に重要な権限で、OAuth 2.0の設計思想の根幹をなしています。

Client（クライアント）

Clientは、Resource Ownerの代理でリソースにアクセスしたいアプリケーションのことです。これはウェブアプリケーション、モバイルアプリ、デスクトップアプリなど、様々な形態をとることができます。

先ほどの例で言えば、あなたのInstagramの写真にアクセスしたい写真編集アプリがClientにあたります。このアプリは、直接あなたのInstagramアカウントにログインするのではなく、OAuth 2.0の仕組みを使ってあなたから許可をもらい、必要な写真データだけにアクセスしようとします。

Clientには、機密情報（クライアントシークレット）を安全に保管できる「Confidential Client」と、保管できない「Public Client」の2種類があります。サーバーサイドで動作するウェブアプリケーションは前者、ブラウザで動作するJavaScriptアプリやモバイルアプリは後者に分類されることが多いです。

Authorization Server（認可サーバー）

Authorization Serverは、アクセス権限（アクセストークン）を発行・管理する役割を担います。これは OAuth 2.0 システムの心臓部と言える重要な存在です。

Instagram の例で言えば、Instagram自身が提供している認可サーバーがこれにあたります。このサーバーは、あなた（Resource Owner）が写真編集アプリ（Client）に対してどのような権限を与えるかを確認し、適切なアクセストークンを発行します。

Authorization Serverは、ユーザーの認証（本当にその人なのかの確認）、権限の確認（どのような操作を許可するかの確認）、そしてトークンの発行・管理を行います。また、発行したトークンが有効かどうかを検証する機能も提供します。

Resource Server（リソースサーバー）

Resource Serverは、実際のデータやAPIを提供するサーバーです。Clientがアクセストークンを提示してAPIを呼び出すと、このサーバーがトークンの有効性を確認して、適切なデータを返します。

Instagram の例では、写真データを保存し、API経由でアクセスを提供しているInstagramのサーバー群がResource Serverにあたります。写真編集アプリから「ユーザーの写真一覧を取得したい」というリクエストが来ると、提示されたアクセストークンを確認し、問題なければ写真データを返します。

Authorization ServerとResource Serverは、同じ組織が運営していることが多く、技術的には同一のサーバー上で動作していることもあります。しかし、概念的には異なる役割を果たしているため、OAuth 2.0の仕様では明確に分離されています。

5. OAuth 2.0の基本的な流れを体験してみよう

理論的な説明だけではわかりにくいので、実際にOAuth 2.0がどのように動作するかを、具体的なシナリオで追ってみましょう。

シナリオ：写真編集アプリでInstagramの写真を加工する

あなたは新しい写真編集アプリ「PhotoMagic」をダウンロードしました。このアプリでは、Instagramの写真を直接読み込んで加工できる機能があると知り、試してみることにしました。

ステップ1：アプリでの操作開始

PhotoMagicアプリを開き、「Instagramから写真を読み込む」ボタンをタップします。すると、アプリは「Instagramアカウントと連携しますか？」という確認画面を表示します。あなたが「はい」を選択すると、OAuth 2.0のプロセスが開始されます。

この段階で、PhotoMagic（Client）は、あなた（Resource Owner）のInstagramの写真（Resource）にアクセスするための権限を求めています。

ステップ2：Instagramの認証画面への移動

PhotoMagicアプリは、あなたのスマートフォンのブラウザを自動的に開き、Instagramの認証ページに移動させます。この画面では、あなたのInstagramのユーザー名とパスワードの入力が求められます。

重要なのは、この時点でパスワードを入力しているのはInstagram自身のページであり、PhotoMagicアプリがあなたのパスワードを見ることは一切ないということです。これがOAuth 2.0の大きな安全性上の利点です。

ステップ3：権限の確認と同意

Instagramにログインすると、「PhotoMagicがあなたの写真にアクセスすることを許可しますか？」という権限確認画面が表示されます。この画面には、PhotoMagicが具体的にどのような操作を行うかが詳細に記載されています。

たとえば、「あなたの写真を閲覧する」「写真にいいねを付ける」といった権限が列挙され、それぞれに対してあなたが許可するかどうかを選択できます。あなたが「許可」を選択すると、Instagramはその旨を記録します。

ステップ4：アクセストークンの発行

あなたの許可を受けて、Instagram（Authorization Server）は特別な「アクセストークン」を生成します。このトークンは、PhotoMagicがあなたの写真にアクセスするための一時的な鍵のようなものです。

トークンには、「誰が」「何に対して」「どのような操作を」「いつまで」許可されているかという情報が含まれています。そして、このトークンをPhotoMagicアプリに送信します。

ステップ5：写真データの取得

アクセストークンを受け取ったPhotoMagicアプリは、このトークンを使ってInstagramのAPI（Resource Server）に写真データの取得を要求します。Instagram側では、提示されたトークンが有効であることを確認した上で、あなたの写真データをPhotoMagicに送信します。

ステップ6：アプリでの写真加工

ついに、PhotoMagicアプリであなたのInstagramの写真を加工できるようになりました。アプリは取得した写真データを使って、様々な加工機能を提供します。

このプロセス全体を通して、PhotoMagicアプリはあなたのInstagramのパスワードを知ることなく、また必要最小限の権限のみで、写真データにアクセスすることができました。そして、あなたはいつでもInstagramの設定画面からPhotoMagicのアクセス権限を取り消すことができます。

6. OpenID Connectによる認証機能の追加

OAuth 2.0は優れた認可システムですが、実際のウェブサービスでは「ログイン機能」として使いたいケースが多くあります。しかし、OAuth 2.0は「認可」のためのフレームワークであり、「認証」については明確に定義されていませんでした。

この課題を解決するために開発されたのが、OpenID Connect（OIDC）です。OIDCは、OAuth 2.0を拡張して認証機能を追加した仕様で、現在では多くのサービスでSSO（シングルサインオン）機能の基盤として使用されています。

ID Tokenという革新

OIDCの最も重要な追加要素は「ID Token」です。これは、JWT（JSON Web Token）という形式で発行される、ユーザーの身元情報を含むトークンです。

ID Tokenには、ユーザーの一意識別子、発行者情報、有効期限、対象クライアントなどの情報が含まれています。さらに、デジタル署名が付与されているため、受け取ったクライアントアプリケーションは、そのトークンが改ざんされていないことを確認できます。

たとえば、あなたが新しいウェブサービスに「Googleアカウントでログイン」した場合、Googleから発行されるID Tokenには、あなたのGoogle内での識別子、名前、メールアドレスなどの基本情報が含まれます。ウェブサービス側は、このID Tokenを検証することで、あなたが確実にGoogleで認証されたユーザーであることを確認できます。

UserInfoエンドポイントによる詳細情報取得

ID Tokenには基本的な情報のみが含まれることが多いため、より詳細なユーザー情報が必要な場合は、UserInfoエンドポイントを使用します。これは、アクセストークンを使ってユーザーのプロフィール情報を取得するための専用APIです。

たとえば、プロフィール写真、誕生日、住所、電話番号などの詳細情報は、UserInfoエンドポイント経由で取得することが一般的です。これにより、ID Tokenのサイズを適切に保ちながら、必要に応じて詳細な情報を取得できます。

Discovery機能による設定の自動化

OIDCでは、プロバイダーの設定情報を自動的に取得するDiscovery機能も提供されています。クライアントアプリケーションは、プロバイダーの「/.well-known/openid-configuration」エンドポイントにアクセスすることで、認可エンドポイントURL、トークンエンドポイントURL、サポートしているスコープなどの情報を自動取得できます。

これにより、プロバイダーが設定を変更した場合でも、クライアントアプリケーションを修正することなく対応できるようになります。

7. OAuth/OIDCがもたらすメリット

OAuth 2.0とOpenID Connectの普及により、私たちのデジタルライフは大きく改善されました。具体的にどのようなメリットがあるのでしょうか。

パスワード管理の負担軽減

まず最も実感しやすいのが、パスワード管理の負担軽減です。OAuth/OIDCが普及する前は、利用するサービスごとに個別のアカウントを作成し、それぞれ異なるパスワードを覚える必要がありました。セキュリティを考慮すると、サービスごとに複雑で異なるパスワードを設定することが推奨されていましたが、これは一般ユーザーにとって大きな負担でした。

OAuth/OIDCにより、信頼できるプロバイダー（GoogleやMicrosoftなど）のアカウント一つで、多数のサービスにログインできるようになりました。これにより、覚えるべきパスワードの数が大幅に削減され、結果的により強固なパスワードを使用できるようになりました。

セキュリティの大幅な向上

OAuth/OIDCは、従来のパスワード認証と比較して、はるかに高いセキュリティを提供します。第三者アプリケーションがユーザーのパスワードを知る必要がないため、パスワードの漏洩リスクが大幅に軽減されます。

また、アクセストークンには有効期限があり、必要に応じて即座に無効化できるため、万が一の場合の被害を最小限に抑えることができます。さらに、スコープという仕組みにより、アプリケーションに必要最小限の権限のみを与えることができ、過度な権限付与を防げます。

シームレスなサービス連携

OAuth/OIDCにより、異なるサービス間での連携が非常にスムーズになりました。たとえば、カレンダーアプリがメールサービスと連携して会議の招待状を自動で予定に追加したり、写真管理アプリがクラウドストレージサービスと連携してバックアップを自動化したりできます。

これらの連携は、ユーザーが一度権限を許可するだけで、継続的に安全に動作します。ユーザーは複雑な設定や手動でのデータ移行を行う必要がなく、各サービスの得意分野を活かした統合的なエクスペリエンスを享受できます。

開発者にとってのメリット

開発者にとっても、OAuth/OIDCは大きなメリットをもたらします。認証システムを一から構築することなく、信頼性の高いIDプロバイダーの機能を活用できるため、開発コストと時間を大幅に削減できます。

また、業界標準の仕様に準拠することで、豊富なライブラリやツールを活用でき、セキュリティのベストプラクティスも自動的に適用されます。さらに、グローバルなユーザーベースを持つプロバイダーと連携することで、世界中のユーザーに簡単にサービスを提供できるようになります。

8. OAuth/OIDCの課題と限界

多くのメリットをもたらすOAuth/OIDCですが、一方でいくつかの重要な課題も存在します。これらの課題を理解することは、現在のシステムの限界を知り、将来の技術発展の方向性を考える上で重要です。

中央集権化への依存

OAuth/OIDCの最も大きな課題の一つは、特定の大手IDプロバイダーへの依存が進んでいることです。現在、多くのウェブサービスでは「Googleアカウントでログイン」「Facebookアカウントでログイン」「Microsoftアカウントでログイン」といった選択肢が提供されていますが、これらの企業が提供するサービスに障害が発生したり、ポリシーが変更されたりすると、連携しているすべてのサービスに影響が及びます。

実際に、過去にはGoogleやFacebookのサービス障害により、多数のウェブサービスでログインできなくなるという事態が発生しています。これは、デジタルインフラの重要な部分が少数の企業に集中している現代のインターネットの脆弱性を浮き彫りにしています。

また、これらの大手プロバイダーは、自社のビジネス戦略に基づいてサービスの仕様を変更したり、新しい制限を設けたりすることがあります。そのような変更は、連携しているサービスの開発者やユーザーにとって予期せぬ影響をもたらすことがあります。

プライバシーに関する懸念

OAuth/OIDCシステムでは、IDプロバイダーがユーザーのログイン履歴や、どのサービスをいつ利用したかという詳細な情報を収集しています。これらの情報は、ユーザーの行動パターンを詳細に把握するための貴重なデータとなります。

たとえば、あなたがGoogleアカウントで様々なサービスにログインするたびに、Googleはその情報を記録しています。どの時間帯にどのようなサービスを利用するか、どの程度の頻度で利用するかといった情報から、あなたの生活パターンや興味関心を推測することが可能になります。

これらの情報は、ターゲティング広告の精度向上などに活用される場合がありますが、ユーザーにとってはプライバシーの観点から懸念があります。特に、ユーザーが明示的に同意していない目的でデータが利用される可能性があることは、重要な問題です。

データの囲い込みとベンダーロックイン

現在のOAuth/OIDCシステムでは、ユーザーの個人情報やアカウント情報は、各IDプロバイダーのシステム内に保存されています。これにより、ユーザーが別のプロバイダーに移行したいと思っても、簡単には移行できないという「ベンダーロックイン」の状況が生まれています。

たとえば、長年Googleアカウントを使って様々なサービスを利用してきたユーザーが、何らかの理由でMicrosoftアカウントに移行したいと思ったとしても、それは簡単ではありません。連携しているすべてのサービスで新しいアカウントとの連携設定を行い直す必要があり、場合によっては過去のデータを失う可能性もあります。

トークンのセキュリティリスク

OAuth/OIDCでは、アクセストークンという重要な情報がクライアントアプリケーション側に保存されます。これらのトークンが適切に管理されない場合、セキュリティリスクとなる可能性があります。

特に、モバイルアプリやウェブブラウザで動作するアプリケーションでは、トークンの保護が技術的に困難な場合があります。悪意のあるソフトウェアや、アプリケーションの脆弱性により、トークンが盗まれる可能性もあります。

また、長期間有効なリフレッシュトークンが漏洩した場合、攻撃者が長期間にわたってユーザーのアカウントに不正アクセスできる可能性があります。

スケーラビリティとパフォーマンスの課題

大規模なシステムでOAuth/OIDCを運用する場合、IDプロバイダーへの依存がパフォーマンスのボトルネックとなる可能性があります。ユーザーがサービスにアクセスするたびに、IDプロバイダーのサーバーとの通信が必要になるため、ネットワークの遅延やプロバイダー側の負荷状況が、すべての連携サービスのパフォーマンスに影響を与えます。

また、IDプロバイダーのAPIには利用制限（レート制限）が設けられている場合が多く、大量のユーザーを抱えるサービスでは、これらの制限に達してしまう可能性もあります。

9. web3との交差点

これらの背景や課題を受け、web3ではユーザーが自分のデータとアイデンティティを完全に制御する「自己主権型アイデンティティ」の概念が重要視されています。

ウォレットベース認証の台頭

暗号通貨の普及とともに、デジタルウォレットを使った認証方式が注目されています。これは、ユーザーが秘密鍵を使ってメッセージにデジタル署名を行い、その署名をサーバー側で検証することで認証を行う方式です。

この方式では、ユーザーは自分の秘密鍵を完全に管理し、それを第三者に渡すことはありません。これは、OAuth/OIDCの理念をさらに発展させた形と言えるでしょう。

相互運用性の新たな挑戦

Web3の世界では、異なるブロックチェーンネットワーク間でのアイデンティティの相互運用性が重要な課題となっています。OAuth/OIDCで培われた標準化の経験は、この新しい領域でも活かされることが期待されています。

まとめ

本記事では、OAuth 2.0とOpenID Connectの基本的な仕組みから、実際の利用場面、そして現在の課題まで、幅広く解説してきました。

OAuth 2.0は「限定的な認可」をトークンベースで実現する革新的な仕組みであり、OpenID Connectはそこに「ユーザー認証」機能を追加した実用的な拡張です。これらの技術により、私たちは安全で便利なデジタルサービスを享受できるようになりました。

しかし同時に、中央集権的な構造に起因する依存性の問題、プライバシーの懸念、データの囲い込みといった課題も明らかになっています。これらの課題は、単純に技術的な改良だけで解決できるものではなく、インターネット全体のアーキテクチャやガバナンスの在り方に関わる根本的な問題です。

次回の後編では、これらの課題を解決する可能性を秘めた次世代技術として、DID（分散型識別子）とVC（検証可能な認証情報）を中心とした自己主権型アイデンティティ管理について詳しく解説します。

免責事項：リサーチした情報を精査して書いていますが、個人運営&ソースが英語の部分も多いので、意訳したり、一部誤った情報がある場合があります。ご了承ください。また、記事中にDapps、NFT、トークンを紹介することがありますが、勧誘目的は一切ありません。全て自己責任で購入、ご利用ください。

🗓️イベント情報

• 0から学ぶweb3基礎勉強会 #1 ~DePIN~
  • 7月14日(月)@名古屋
  • 7月15日(火)@東京
  • 7月15日(火)@オンライン（東京回をオンライン配信）
• OrbsCafe #12　『Ethereum徹底解説』（登壇）
  • 7月27日(日)@東京

About us：「web3 for everyone」をコンセプトに、web3の注目トレンドやプロジェクトの解説、最新ニュース紹介などのリサーチ記事を毎日配信しています。

Author：mitsui @web3リサーチャー
「web3 Research」を運営し、web3リサーチャーとして活動。

Contact：法人向けのリサーチコンテンツの納品や共同制作、リサーチ力を武器にしたweb3コンサルティングや勉強会なども受付中です。詳しくは以下の窓口よりお気軽にお問い合わせください。（📩 X / HP）

→お問い合わせ先はこちら