私のメンター探しログ

モダン認証認可 OAuth OIDC 仕組みと基本

Tags: 認証, 認可, OAuth, OpenID Connect, Web開発

はじめに

Webサービス開発やモダンなアプリケーション連携において、ユーザーの認証（誰であるかを確認すること）と認可（何ができる権限を持つかを確認すること）は、セキュリティの根幹をなす重要な要素です。SIerでの開発経験がある方の中には、従来のシステムにおける認証認可の仕組みに慣れている方もいらっしゃるかもしれません。しかし、事業会社で展開されるようなマイクロサービスやAPI連携が主流となる環境では、より柔軟かつセキュアな認証・認可の技術が求められます。

特に、OAuth 2.0とOpenID Connect（OIDC）は、現代のWebサービスにおいてデファクトスタンダードとも言える技術です。これらの技術は、ユーザーの同意に基づいて安全に情報連携を行う仕組みを提供します。この記事では、OAuth 2.0とOpenID Connectの基本的な仕組みと、なぜこれらがモダンな開発において重要視されるのかについて解説します。

認証と認可の違い

まず、認証と認可の概念を明確にしておきます。

OAuth 2.0は主に「認可」のためのフレームワークであり、OpenID ConnectはOAuth 2.0を拡張して「認証」の機能を提供するものです。この関係性を理解することが、両者の仕組みを把握する上で重要になります。

OAuth 2.0の仕組み：安全な認可のフレームワーク

OAuth 2.0は、ユーザーが自分のデータやリソースへのアクセス権限を、自身のIDやパスワードを共有することなく、別のアプリケーションに安全に委任するための「認可フレームワーク」です。

登場人物は主に以下の4者です。

OAuth 2.0の代表的な認可フローの一つに「Authorization Code Grant」があります。このフローは、Webサーバー型のアプリケーションで広く用いられます。

  1. クライアントは、リソースオーナーを認可サーバーへリダイレクトします。このとき、クライアントID、リダイレクトURI、要求する権限の範囲（Scope）などを伝えます。
  2. リソースオーナーは認可サーバーで認証を行い（ここで認証が登場します）、クライアントに自身の情報へのアクセスを許可するかどうか同意します。
  3. リソースオーナーが同意すると、認可サーバーはリソースオーナーをクライアントのリダイレクトURIへリダイレクトします。このとき、一時的な「認可コード (Authorization Code)」が付与されます。
  4. クライアントは、受け取った認可コードと自身のクライアントシークレットを使って、認可サーバーの「トークンエンドポイント」に直接リクエストを送ります。
  5. 認可サーバーは受け取った認可コードとクライアントシークレットを検証し、正当であれば「アクセストークン (Access Token)」を発行します。場合によっては「リフレッシュトークン (Refresh Token)」も発行されます。
  6. クライアントは、取得したアクセストークンをResource Serverへのリクエストに含めることで、保護されたリソースにアクセスします。
  7. Resource Serverは、受け取ったアクセストークンを検証し、有効であればリソースへのアクセスを許可します。

重要なのは、リソースオーナーはクライアントに自身の認証情報（ID/パスワード）を直接渡す必要がない点です。これにより、セキュリティリスクを低減しつつ、安全な連携を実現しています。

OpenID Connectの仕組み：認証レイヤーとしての役割

OpenID Connectは、OAuth 2.0フレームワークの上に構築されたシンプルで相互運用可能な認証レイヤーです。つまり、OAuth 2.0をベースにしながら、認証の機能を提供します。

OIDCの主な目的は、クライアントがユーザーのアイデンティティ（誰であるか）を、認可サーバー（ここではOpenID Providerと呼ばれます）によって検証し、そのアイデンティティに関する基本的なプロファイル情報（ユーザー名、メールアドレスなど）を取得できるようにすることです。

OIDCの中心となる要素は「IDトークン (ID Token)」です。これはJSON Web Token (JWT) 形式で表現されることが一般的です。

OAuth 2.0のフローにOIDCが加わると、以下のようになります（Authorization Code Flowの場合）。

  1. クライアントは、OAuth 2.0と同様にリソースオーナーを認可サーバー（OpenID Provider）へリダイレクトしますが、要求するScopeにopenidを含めます。openidスコープはOIDC認証を要求することを示します。
  2. リソースオーナーはOpenID Providerで認証を行います。
  3. リソースオーナーが同意すると、OpenID ProviderはクライアントのリダイレクトURIへ認可コードを付けてリダイレクトします（OAuth 2.0と同じ）。
  4. クライアントは認可コードを使ってOpenID Providerのトークンエンドポイントにリクエストを送ります（OAuth 2.0と同じ）。
  5. OpenID Providerはアクセストークンに加えて、IDトークンを発行します。
  6. クライアントはIDトークンを受け取り、ユーザーのアイデンティティ情報を検証できます。IDトークンには、ユーザーを一意に識別するためのsub（Subject）クレームや、認証が行われた時刻などの情報が含まれています。
  7. 必要に応じて、クライアントはアクセストークンを使用して、OpenID Providerの「UserInfo Endpoint」からユーザーに関する追加のプロファイル情報を取得することも可能です。

OIDCは、主にシングルサインオン（SSO）の実装や、異なるサービス間でのユーザー情報の連携に広く利用されています。OAuth 2.0が「アクセス権限の委譲」に特化しているのに対し、OIDCは「ユーザーの認証とアイデンティティ情報の取得」に特化している、と理解できます。

モダンな開発における重要性

OAuth 2.0とOpenID Connectが現代の事業会社で重要視される理由はいくつかあります。

これらの技術は、SIerでの開発ではあまり扱う機会がなかったかもしれませんが、事業会社でのWeb開発やクラウドネイティブな開発においては必須の知識となります。自身のキャリアアップや転職を目指す上で、OAuth/OIDCの仕組みを理解し、実践的なスキルを身につけることは非常に有益です。

まとめ

この記事では、認証と認可の基本的な違いを確認し、モダンなWebサービス開発において広く用いられるOAuth 2.0とOpenID Connectの仕組みについて解説しました。

これらの技術を理解することは、モダンなアプリケーション設計やAPI連携の基礎を学ぶ上で不可欠です。特に、SIerから事業会社への転職を目指す方にとっては、自身の技術スタックをアップデートし、モダン開発への対応力を示す上で非常に有効な学習テーマと言えます。

もし、これらの技術についてさらに深く学びたい、自身のプロジェクトにどう適用すればよいか具体的なアドバイスが欲しい、といった課題をお持ちであれば、関連分野に詳しいメンターを探してみることも有効な選択肢の一つとなるでしょう。体系的な知識の習得から実践的な疑問の解消まで、メンタリングは技術力向上の一助となります。