auth認証と呼ばれる仕組みの正体
「auth」はauthentication（認証）とauthorization（認可）の両方を縮めた表記として使われるため、文脈によって指すものが変わります。実務で登場する代表的な3つを、それぞれ何のための技術なのかという視点で整理します。
OAuthはデータ利用を許可するための仕組み
OAuth（オーオース）は、あるサービスが持つ利用者のデータを、別のサービスに安全に使わせるための規格です。現在広く使われているのはOAuth 2.0で、写真共有サイトの画像を印刷サービスに渡す、会計ソフトに銀行の明細を読み込ませるといった連携の裏側で動いています。重要なのは、OAuthが本来「認可」の規格であり、本人確認そのものを目的にしていない点です。
従来は、外部サービスに自分のIDとパスワードをそのまま預ける方法が取られていました。この方式では、預けた先が不正アクセスを受けた瞬間にアカウント全体が乗っ取られます。OAuthは、パスワードを渡す代わりに「この範囲だけ、この期間だけ使ってよい」という許可証（アクセストークン）を発行する形に置き換え、被害範囲を限定できる設計にしました。
この記事をご覧の方には、以下の記事もおすすめです。あわせて参考にしてください。
OpenID ConnectはOAuthに本人確認を足した規格
OpenID Connect（オープンアイディー・コネクト、略してOIDC）は、OAuth 2.0の上に「利用者が誰であるか」を伝える層を重ねた規格です。「Googleでログイン」「Microsoftアカウントでログイン」といったソーシャルログインの多くは、OAuthそのものではなくOpenID Connectで実現されています。IDトークンと呼ばれる、改ざん検知が可能な形式の情報が発行される点が特徴です。
IDトークンには、利用者を一意に示す識別子、発行元、有効期限などが含まれ、受け取った側は署名を検証して内容を信頼できます。OAuthのアクセストークンには本来こうした本人情報を保証する役割がないため、ログイン機能を作るのであればOpenID Connectを選ぶのが基本的な考え方です。
SMTP-AUTHはメール送信時の送信者確認
SMTP-AUTHは、メールを送信する際にメールサーバーが送信者を確かめる仕組みで、前述の2つとは目的も系統も異なります。かつてのメール送信では送信者の確認が行われず、誰でもサーバーを経由してメールを送れる状態でした。この状態は迷惑メールの踏み台として悪用されるため、送信時にもIDとパスワードで本人確認を行う方式が標準になりました。
メールソフトの設定画面に並ぶ「送信サーバーは認証が必要」という項目が、これに当たります。近年は、パスワードそのものを送らずOAuth 2.0の許可証を用いてメール送信を認可する方式へ移行するサービスも増えており、3つの仕組みが実務では地続きになっている点も知っておくと役立ちます。
認証と認可の違いを正しく切り分ける
auth関連の理解でつまずく最大の原因は、認証と認可の混同です。似た言葉でありながら担う役割は別で、混同したときに何が起きるのかを具体的に確認します。
認証は「誰か」、認可は「何を許すか」
認証は、目の前の相手が本人であることを確かめる行為です。パスワードの入力、スマートフォンへの確認コード送信、指紋や顔の照合はすべて認証に当たります。一方の認可は、確かめた相手に対して「どの情報を、どこまで操作してよいか」を決める行為です。会社の入館証にたとえるなら、受付での顔写真照合が認証、カードで開く扉の範囲が認可です。
この切り分けを意識すると、OAuthが認可の規格である意味が明確になります。OAuthのアクセストークンは「扉を開ける権限」を示すものであって、「持ち主が誰か」を保証しません。拾った入館証で扉が開いてしまうのと同じ状況が、設計を誤ると発生します。
OAuthを認証代わりに使うと生じる問題
アクセストークンを受け取り、それを使って外部サービスのプロフィール取得APIを呼び、返ってきたユーザーIDでログインさせる。この実装は一見動作しますが、危険をはらんでいます。悪意ある開発者が、自分のアプリで利用者から得たアクセストークンを、別のサービスに横流しできてしまう構造があるためです。
受け取った側は、そのトークンが自分のために発行されたのかを確認できません。結果として、他人になりすましたログインが成立する余地が残ります。OpenID ConnectのIDトークンには「誰に向けて発行したか」を示す項目が含まれ、検証によってこの攻撃を防げます。ログイン機能では認可の規格を流用しないことが重要です。
この記事をご覧の方には、以下の記事もおすすめです。あわせて参考にしてください。
OAuth 2.0が動く手順を追う
仕組みの理解には、通信の流れをたどるのが近道です。登場人物を整理したうえで、推奨される認可コードフローの手順と許可証の扱いを見ていきます。
登場する4者の役割を押さえる
OAuthには4つの立場が登場します。1つ目はリソースオーナーで、データの持ち主である利用者本人です。2つ目はクライアントで、データを使いたい外部アプリケーションを指します。3つ目は認可サーバーで、利用者に許可を求めて許可証を発行します。4つ目はリソースサーバーで、実際のデータを保管し、許可証を確認して提供します。
写真印刷サービスが写真共有サイトの画像を取得する場面に当てはめると、利用者がリソースオーナー、印刷サービスがクライアント、写真共有サイトのログイン画面が認可サーバー、画像を保管する部分がリソースサーバーです。この4者を意識すると、以降の流れが追いやすくなります。
認可コードフローの流れ
手順は次のとおりです。(1)利用者がクライアントで連携を開始すると、認可サーバーの画面へ転送されます。(2)利用者はそこでログインし、「このアプリに写真の読み取りを許可しますか」という同意画面で内容を確認します。(3)許可すると、認可サーバーは一時的な引換券である認可コードをクライアントへ返します。
(4)クライアントは、その認可コードと自身の秘密情報を認可サーバーの裏側の窓口へ送り、アクセストークンと交換します。この交換を利用者のブラウザを介さないサーバー間の通信で行うため、トークンが第三者に見られる危険を抑えられます。(5)以降、クライアントはトークンを添えてリソースサーバーからデータを取得します。
アクセストークンとリフレッシュトークン
アクセストークンには有効期限が設けられ、数十分から数時間で失効する設計が一般的です。仮に漏えいしても、悪用できる時間を短く抑えるための工夫です。期限が切れるたびに利用者へ同意を求め直すのは現実的でないため、再発行用のリフレッシュトークンが併せて渡されます。
リフレッシュトークンは長期間有効なため、クライアント側での保管方法が問われます。暗号化して保存する、利用者が連携を解除した時点で確実に失効させるといった運用が求められます。連携を解除できる画面を利用者に用意することも、実装側の責任範囲に含まれます。
ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料を取り寄せて、さまざまな製品の機能や特徴を比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力（約60秒）でID管理の一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。
身近な利用例に潜むリスク
OAuthやOpenID Connectは利便性を高めた一方で、仕組みを逆手に取る攻撃も生まれています。日常的に目にする場面で起きうる被害を確認しましょう。
同意画面を悪用する攻撃
近年増えているのが、正規の認可サーバーの同意画面をそのまま使う攻撃です。攻撃者は、業務に関係がありそうな名前のアプリを事前に登録しておき、メールなどで連携を促すリンクを送ります。利用者が表示された画面で内容を確かめずに「許可」を押すと、メールの読み取り権限などが攻撃者の手に渡ります。
この手口の厄介な点は、偽サイトへ誘導するフィッシングと違い、ログイン画面自体は本物であることです。URLを確認しても見分けが付きません。パスワードを盗まれたわけではないため、パスワード変更や多要素認証だけでは被害を止められず、連携の解除が必要になります。アプリ名と要求されている権限の範囲を必ず読む習慣が防御になります。
この記事をご覧の方には、以下の記事もおすすめです。あわせて参考にしてください。
スコープと連携状況の棚卸し
スコープとは、許可する権限の範囲を示す指定です。「プロフィールの読み取りのみ」と「メールの送信も含む」では、万一の際の被害が大きく変わります。サービスを提供する側は必要最小限のスコープだけを求め、利用する側は要求内容が用途に見合うかを確認する姿勢が求められます。
また、一度許可した連携は解除するまで有効であり続けます。退職者のアカウントに残った連携や、使わなくなったツールへの許可が放置される事例は珍しくありません。主要なサービスにはアカウント設定から連携アプリの一覧を確認する画面があり、定期的な棚卸しによって不要な権限を減らせます。
業務システムで認証基盤を整える際の検討点
次は自社でどう扱うかという段階です。個別に実装するか認証基盤のサービスを利用するかで、必要な手間と安全性は変わります。検討時に見るべき観点を整理します。
対応プロトコルと既存システムとの連携範囲
最初に確認したいのは、対応している規格の種類です。社内で使うクラウドサービスがSAMLに対応しているか、OpenID Connectに対応しているかで、選べる選択肢が変わります。両方に対応し、さらに社内のActive Directoryなど既存の利用者情報と同期できるかどうかも、移行の負担を左右する重要な条件です。
自社開発のアプリケーションに認証機能を組み込みたい場合は、OpenID Connectで連携できるかを確認します。規格に沿った実装を自前で行うと、署名の検証や有効期限の扱いなど考慮点が多く、抜け漏れが事故に直結します。実績のある基盤に任せる判断が現実的な場面は多くあります。
多要素認証と費用・運用体制の目安
認証を一か所に集約すると、そこが突破された際の影響も集中します。そのため、パスワードに加えてスマートフォンのアプリや生体情報を組み合わせる多要素認証の対応可否は、確認すべき条件です。接続元の場所や端末の状態に応じて許可を判断できるかどうかも、あわせて見ておきたい点です。
費用は利用者1人あたりの月額で設定される形式が一般的で、機能の範囲によって幅があります。導入後は、入退社に伴う登録と削除、連携アプリの棚卸しといった運用が継続して発生します。誰が担当し、どの頻度で確認するかを決めてから選定に入ると、導入後の負担を見誤りにくくなります。
この記事をご覧の方には、以下の記事もおすすめです。あわせて参考にしてください。
認証基盤の導入で検討したいサービス
OpenID ConnectやSAMLといった規格に対応し、社内外のサービスへのログインを一元的に扱えるサービスを紹介します。自社の利用環境に合うかの参考にしてください。
Okta Workforce Identity
- フィッシングに強い認証フローでログインをより簡単・安全にする
- ADやLDAP等と統合。全てのIDを単一コントロールプレーンから管理
- ユーザーのアクセスを1か所で管理しアクティビティを適切に把握
Okta Japan株式会社が提供する「Okta Workforce Identity」は、従業員が利用するクラウドサービスや社内システムへの認証とアクセスを一元管理するIDaaSです。シングルサインオンにより、一度の認証で複数のアプリケーションへアクセスでき、8,000以上のアプリとの連携に対応しています。多要素認証やフィッシング耐性のあるパスワードレス認証を備え、利便性とセキュリティを両立できる点が特徴です。Active DirectoryやLDAP、人事システムとも連携でき、入退社や異動に伴うアカウントの作成・更新・停止も自動化できます。
Soliton OneGate （株式会社ソリトンシステムズ）
- デジタル証明書MFAで不正アクセス防止
- AD連携でID・証明書運用を自動化し管理負担を軽減
- 代理認証でパスワード管理から解放
まとめ
auth認証という言葉は、データ利用を許可するOAuth、本人確認を担うOpenID Connect、メール送信時に送信者を確かめるSMTP-AUTHのいずれかを指します。特にOAuthは認可の規格であり、ログイン機能に流用すればなりすましの余地を残します。認証と認可を切り分けて理解し、同意画面の内容確認と連携の定期的な棚卸しを習慣づけることが安全な運用につながります。業務での本格利用では、規格への対応範囲と多要素認証、運用体制を軸に基盤を選定しましょう。
