検索
連載

「OAuth 2.0」の基本動作を知るデジタルID最新動向(1)(3/4 ページ)

SNSなど複数のWebサービスが連携して動くサービスが広く使われている。連携に必要不可欠なのが、アクセス権限をセキュアに受け渡すための仕組みだ。本連載ではこのような仕組みのうち、「OAuth 2.0」や「OpenID Connect」「SCIM」の最新動向と技術の内容を紹介する。

Share
Tweet
LINE
Hatena

ユースケース2:Facebookアカウントでイベント管理サービス(Webアプリ)にログイン

 ユースケース2は「ソーシャルログイン」として広く認識されている動作です。前提条件は2つ。

  • Facebookアカウントを持っているユーザーが、イベント管理サービスを利用する
  • イベント管理サービスは、Facebookアカウントを用いてユーザーを自サービスへログインさせる機能を持つ

 ユースケース2では、IT勉強会支援プラットフォーム「connpass」における「Facebookアカウントを用いたソーシャルログイン」の流れを紹介します。それぞれの役割は次のようになります。はてなブログの例とほぼ同じですね。

役割 実体
Resource Owner ユーザー
Client connpassのサーバ(Webアプリケーション)
Resource Server Facebookのサーバ
Authorization Server Facebookのサーバ

 Client Registrationについても、はてなブログが登場したユースケース1と同様に、connpassはあらかじめFacebookに対して、OAuth 2.0のリクエストを送るための手続きを済ませています。connpassの「ログイン・新規登録」画面を見ると、右側に「○○で登録/ログイン」というボタンが3つ並んでいます(図6)。

図6
図6 connpassとFacebookに見るOAuth 2.0の動作

 ユーザーが「Facebookで登録/ログイン」というボタンを押すと、Facebookに遷移します(図7)。そこで「connpass」に対して「公開プロフィール、友達リスト、メールアドレス」などへのアクセスを許可する必要があります(connpassも記事の投稿を要求してきますが、ここではソーシャルログインの説明ということで触れません)。

図7
図7 Facebookがユーザーにアクセス許可を求めてきた

 ユースケース2では1と同様に、Facebook側では以下のような処理を進めています。

  • connpassが記事投稿の許可を求めていることを把握
  • ユーザーのFacebookアカウントを特定(未ログイン状態であればログインさせる)
  • ユーザーに「connpassに対してプロフィール情報などへのアクセスを許可する」ことについて同意を求める
  • connpassに対してプロフィール情報などへのアクセスを許可するといった処理

 ここまでが定義2で定めたObtaining Authorizationの処理です。ユースケース1と同じですね。

 connpassは「登録/ログイン」のためにすぐにユーザーのプロフィール情報とメールアドレスをFacebookから取得して、「登録/ログイン」の処理に利用します。この部分は定義3のAccessing Protected Resourcesの処理に当たります(図8)。

図8
図8 connpassとFacebookに見るOAuth 2.0の動作(全体像)

 connpassの画面を見る限りでは、次の3つの処理を進めていると考えられます。

  • 取得したユーザー識別子を用いて会員登録済みかどうかを判定
  • 登録済みであればログインさせる
  • 未登録であれば新規登録させる

 新規登録フローに入った画面を見ると、「名前」と「メールアドレス」を入力フォームに補完する形で利用しています(図9)。connpassがユーザーに代わってプロフィール情報とメールアドレスを参照し、取得した値を登録フローに利用しているということになります。

図9
図9 connpassとFacebookに見るOAuth 2.0の動作(連携完了後)

重い処理を安全に実装することがカギ

 ユースケース1との違いは、2つあります。

  1. connpassがFacebookに「プロフィール情報,メールアドレスの参照」の許可を要求し、許可を得て取得した情報を「登録/ログイン」処理に利用している
  2. 「プロフィール情報,メールアドレスの参照」の許可を得るObtaining Authorizationのタイミングと、実際に「プロフィール情報,メールアドレスの参照」を行うAccessing Protected Resourcesのタイミングがほぼ同一である

 「1」についてユーザーが見る限り、「登録/ログイン」のためにこの処理に入ること、Facebookも「○○としてログイン」のような画面表示をしていることから、特に違和感はありません。

 しかし、ユーザー識別子を含むプロフィール情報の参照という比較的「軽い」処理とアカウントの「登録/ログイン」という「重い」処理が連続しています。「重い」処理を行うということは、ユーザー識別子を提供するまでの処理を安全に実装しなければアカウント乗っ取りなどの大きなリスクが発生し得るということを意識しなければなりません。適切な仕様を選択、実装する必要があります。

 「2」については「Facebookで新規登録/ログイン」を押したタイミングで、毎回Obtaining AuthorizationとAccessing Protected Resourcesが実行されていることが分かります。

Copyright © ITmedia, Inc. All Rights Reserved.

Security & Trust 記事ランキング

  1. 「生成AIのサイバー攻撃への悪用」は増加する? 徳丸浩氏が予測する2025年のセキュリティ
  2. AWS、組織のセキュリティインシデント対応を支援する「AWS Security Incident Response」を発表 アラートに圧倒されるセキュリティチームをどう支援?
  3. 商用国家安全保障アルゴリズム(CNSA)の期限となる2030年までに暗号化/キー管理サービス市場が60億ドルに達するとABI Researchが予測 急成長の要因とは?
  4. ChatGPTやClaudeのAPIアクセスをかたってマルウェアを配布するPython用パッケージ確認 Kasperskyが注意喚起
  5. Google、オープンソースのセキュリティパッチ検証ツール「Vanir」を公開 多種多様なAndroidデバイスの脆弱性対応を支援するアプローチとは
  6. 「このままゼロトラストへ進んでいいの?」と迷う企業やこれから入門する企業も必見、ゼロトラストの本質、始め方/進め方が分かる無料の電子書籍
  7. 高度なAIでAIをテスト OpenAIが実践するAIモデルのレッドチーム演習とは
  8. 「SQLite」のゼロデイ脆弱性、GoogleのAIエージェントが見つける AIは脆弱性調査の課題をどう解決したのか?
  9. 従業員は「最新のサイバー脅威との戦い」を強いられている セキュリティ教育に不満を持つ理由の1位は?
  10. 堅調なID管理や認証、脅威インテリジェンスなどを抑え、2024年上半期で最も成長したセキュリティ分野は?
ページトップに戻る