外部アプリの「アクセスを許可」で、何を渡している?OAuthの基本
外部アプリを連携するときの許可画面には、アプリが何をできるかが示されています。OAuthの基本と、連携前・利用中・連携解除時に確認したい点を、ファイル整理アプリの例で説明します。
パスワードの代わりに、アクセスを認める仕組み
ファイル保存サービスに、別の会社が作った整理アプリをつなぐとします。整理アプリがファイルを扱うには、保存サービス側から認められたアクセス手段が必要です。
OAuth 2.0は、第三者のアプリにHTTPサービスへの限定されたアクセスを認めるための枠組みです。基本仕様のRFC 6749では、利用者の認可により、アプリがアクセストークンというアクセス許可を表す情報を使い、保護されたデータなどへアクセスする仕組みが説明されています。
ここで重要なのは、アプリに何が許されるかです。パスワードを直接入力していないからといって、連携後のアプリが何も操作できないわけではありません。
この記事では、OAuthの基本概念とサービスの公式案内をもとに、利用者側の確認を扱います。RFC 6749は2012年の基本仕様であり、現在の安全な実装方式を網羅する手順書として紹介するものではありません。
許可画面では、目的と範囲を照らし合わせる
仮に、整理アプリの目的が「ファイル名の一覧から、重複しそうな名前を見つけること」だったとします。必要なアクセスは、実際の処理方法によって変わります。
許可画面に「ファイルの読み取り」とあれば、名前だけなのか本文も含むのかを確かめます。「編集」や「削除」が含まれていれば、その機能を使う目的があるかを見直します。
権限名だけでは意味が十分に分からない場合もあります。サービスの説明とアプリの提供元の説明を読み、分からないまま広い範囲を許可しないことが、判断の出発点です。
表が見切れる場合は横にスクロールできます
確かめる内容 | 自分に置き換える問い |
|---|---|
アプリと提供元 | 自分が使おうとしていたアプリか |
対象のデータ | 個人のファイルか、共有のデータも含むか |
許可する操作 | 閲覧だけか、変更や削除もできるか |
使う理由 | その操作が、利用したい機能に必要か |
これは許可内容を読むための整理例です。どのサービスでも、表の項目を個別に選択できるという意味ではありません。
連携したあとも、一覧を見直す
試したまま使っていないアプリや、提供元を思い出せないアプリが残っていないか、サービス側の連携一覧を確認します。新しく許可するときだけでなく、使う道具が変わったときにも見直すとよいでしょう。
たとえばGitHubの許可済みOAuthアプリを確認する公式手順では、設定のApplicationsにあるAuthorized OAuth Appsから、認めたアクセスを確認し、取り消す操作が案内されています。
この画面名はGitHubの例です。他のサービスでは「連携アプリ」「接続済みアプリ」など、名称や管理場所が異なります。また、組織の管理者が利用を制御している場合もあります。
仕事で使う連携を解除する前には、何に使われているかも確認します。使っていないと思ったアプリが、定期的な集計などを担当している可能性があるためです。
連携解除と、保存済みデータの削除を分けて考える
アクセスの許可を取り消すことと、アプリがすでに取得して保存したデータを削除することは、同じ操作とは限りません。
たとえばファイルの内容をアプリ側へ複製する機能を使った場合、今後のアクセスを止めただけで、その複製まで消えるとは判断できません。これはデータの移動を考えたときの確認事項であり、特定サービスの保存状況を断定するものではありません。
利用を終えるときは、連携の解除方法に加えて、アプリ側のアカウントや保存データを削除する手順、保持期間の説明を確認します。必要なデータを自分が取り出せるかも、先に確かめておきたい点です。
許可する操作を、一度言葉にしてみる
外部アプリの連携では、「このアプリに、どのデータへの、どんな操作を認めるのか」を説明できるかが判断の助けになります。利用後も、使わなくなった連携を見直す習慣を持つと管理しやすくなります。
連携先とデータの流れを整理する方法は、API連携の基本でも紹介しています。
