Apidog

オールインワンのAPI開発プラットフォーム

API設計

API仕様書生成

APIデバッグ

API Mock

APIテスト自動化

無料登録
Home / 観点 / OAuth2.0の認可コードグランドとは、その仕組みを解説

OAuth2.0の認可コードグランドとは、その仕組みを解説

本文では、Oauth2.0で相互作用をしている各ロールを詳しく解説した上、Oauth2.0の認可コードグランドの仕組みをも解説していこうと思います。また、便利なAPI管理ツールのApidogを使って、OAuth2.0認証を楽に行える方法を一緒に紹介します。

OAuth 2.0の認可コードグラントは、クライアントアプリケーションがリソースオーナー(通常はエンドユーザー)の代理でリソースにアクセスするための、安全な認証フローです。本文では、Oauth2.0で相互作用をしている各ロールを詳しく解説した上、Oauth2.0の認可コードグランドの仕組みをも解説していこうと思います。また、便利なAPI管理ツールのApidogを使って、OAuth2.0認証を楽に行える方法を一緒に紹介します。

💡
API管理ツールのApidogでは、OAuth 2.0の認可コードグラントをはじめ、様々な認可フローに対応しています。アクセストークンの自動取得と、APIリクエストへの自動追加が可能なため、OAuth 2.0の認証を簡単に行えるメリットがあります。Apidogを活用することで、開発者はOAuth 2.0の認証を効率的に実装できます。
button

認可コードグランドとは?

認可コードグランドは、Authorization Code Grantの和訳として、クライアントアプリケーションがリソースオーナー(通常はエンドユーザー)の代理でリソースにアクセスするための、安全な認証フローを指しています。

認可コードグランドの各ロールを説明

OAuth 2.0の認可コードグラントでは、主に以下の4つの主要なロールが相互作業しています。

  1. リソースオーナー
    通常はエンドユーザーのことを指します。リソースオーナーは、クライアントアプリケーションにリソースへのアクセス権を付与するかどうかを決定する存在です。
  2. クライアントアプリケーション
    リソースオーナーに代わってリソースサーバーにアクセスしたいアプリケーションのことです。モバイルアプリやウェブアプリ等がこれにあたります。
  3. 認可サーバー
    クライアントアプリケーションからの認証リクエストを受け取り、リソースオーナーの認可を経て、アクセストークンやリフレッシュトークンを発行する役割を担います。認証情報の検証も行います。
  4. リソースサーバー
    クライアントアプリケーションがアクセスを求めるリソース(API、ユーザーデータ等)を提供するサーバーです。認可サーバーから発行されたアクセストークンを検証し、それに基づいてリソースへのアクセスを許可します。

認可サーバーとリソースサーバーは別々の存在である必要はありませんが、分離することで役割を明確化でき、セキュリティ上の利点があります。大規模なシステムでは分離されていることが多いです。

認可コードグラントの仕組みと流れ

それでは、認可コードグラントでは、各ロールがどのように相互作業していて、どのような流れで認証を済んでいますか?OAuth 2.0の認可コードグラントは主に以下の手順のように進行しています:

  1. クライアントアプリケーションがユーザーをIDプロバイダーの承認サーバーにリダイレクトさせる
  • 例えば、次のように、URLに必要な認証情報を追加します:

  • https://authorization-server.com/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=read_profile

  1. ユーザーはIDプロバイダーでログインし、アプリケーションへのアクセス許可を与える
Redditのアプリの権限を許可
  1. IDプロバイダーがリダイレクトURIにユーザーをリダイレクトし、認可コードを含む
  • 例えば:次のようなURIにリダイレクトされます:

  • https://client-app.com/redirect_uri?code=AUTHORIZATION_CODE

  • このURIの最後の部分は認可コードになります。

  1. クライアントアプリケーションが、この認可コードとクライアントシークレット(クライアント識別子に対するパスワード)をIDプロバイダーに送り、アクセストークンを要求する
POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTHORIZATION_CODE
&redirect_uri=REDIRECT_URI
&client_id=CLIENT_ID
&client_secret=CLIENT_SECRET
  1. IDプロバイダーが検証を行い、アクセストークンを発行する
{
  "access_token": "ACCESS_TOKEN",
  "refresh_token": "REFRESH_TOKEN",
  "token_type": "bearer",
  "expires_in": 3600
}
  1. クライアントアプリケーションがアクセストークンを使って、リソースサーバーからユーザーに代わってリソースにアクセスする
GET /userinfo HTTP/1.1
Host: resource-server.com
Authorization: Bearer ACCESS_TOKEN
認可コードグラントの仕組みと流れ

出典:https://learn.microsoft.com/

他のOAuth 2.0認証フローに比べてみると、OAuth 2.0の認可コードグラントフローでは、リソースオーナー(エンドユーザー)が認証を行う際に、別のウィンドウ(ポップアップ)が開かれることが特徴的です。このフローは、クライアントシークレットを公開せずに済むのでセキュアです。また、拡張機能により、リフレッシュトークンの発行やスコープの設定なども可能になります。モバイルアプリやウェブアプリで幅広く使われています。

認可コードグラントのメリットとデメリット

認可コードグラントは、多くの開発者に汎用されているOAuth 2.0の認可フローになります。認可コードグラントには以下のようなメリットとデメリットがあります。

認可コードグラントのメリット

  1. セキュリティが高い
    クライアントシークレットをクライアントアプリに配置する必要がないため、機密情報が漏洩するリスクが低くなります。
  2. リフレッシュトークンの発行が可能
    アクセストークンの有効期限切れ後も、リフレッシュトークンを使ってトークンを更新できます。
  3. アクセス権の範囲を制限できる
    スコープパラメータを使って、アプリケーションの権限の範囲を細かく制御できます。
  4. 認証コードが時間制限されている
    認証コードの有効期限が短いため、盗難されてもリスクが低くなります。

認可コードグラントのデメリット

  1. フローが複雑
    リダイレクト処理が必要なため、実装が他のフローより複雑になります。
  2. クライアントアプリがサーバー側である必要がある
    認可コードをサーバー側で受け取る必要があるため、ブラウザ拡張機能やNative Clientアプリには不向きです。
  3. リソースオーナーの操作が必須
    リソースオーナーがブラウザで認可を承認する操作が必須なため、自動処理はできません。

全体として、認可コードグラントはセキュリティが高く、柔軟な設定が可能な反面、実装の複雑さがデメリットとなっています。機密情報の取り扱いが重要な場合に適しているフローです。

Apidogでアクセストークン自動取得&追加

非常に使いやすいAPI管理ツールのApidogはOAuth 2.0という認証に完璧に対応できます。ApidogのOAuth 2.0認証機能を利用して、非常に簡単な手順で、OAuth 2.0のアクセストークンを取得し、API認証を行うことができます。

button

ApidogのOAuth 2.0認証機能は、Authorization Code Grant(認可コードグラント)、Authorization Code Grant(With PKCE)、Implicit Grant(暗黙的な許可)、Client Credential Grant(クライアントクレデンシャル)、Password Credential Grant(パスワードクレデンシャル)といった認可フローにも全面的にサポートしています。必要な情報を記入すれば、Apidogはアクセストークンを自動的に取得して、API利用中に自動的に追加することができるので、非常に便利です。

apidogは各Oauth2認証方式にも対応

次の操作ガイドのように、「Auth」タブで、認証方式を選択することで、必要な情報を記入すれば、簡単にトークンを取得することができます。この後、リクエストを送信する度、これらのトークン情報がリクエストに追加されるので、非常に便利です。

ステップ⒈リクエストを送信する際、Apidogで「Auth」タブに切り替えて、認証タイプのドロップダウンリストから「Auth 2.0」を選択します。

ApidogでAuth種類を選択

ステップ⒉必要な情報を記入して、「トークンの取得」ボタンをクリックします。

Oauthの情報を記入

ステップ⒊記入の情報に問題がなければ、アクセストークンが成功に取得れます。ここで、リクエストを送信する際は、アクセストークンが自動的に追加され、OAuth認証を行うことができます。

OAuthのアクセストークンの取得

また、ここでトークンの有効期限もちゃんと表示され、必要に応じて、トークンを再度取得したり、トークンを削除したりすることもできるので、非常に便利です。

button

まとめ

OAuth 2.0の認可コードグラントは、クライアントアプリケーションがリソースオーナー(通常はエンドユーザー)の代理でリソースにアクセスするための、安全な認証フローです。この認証フローでは、リソースオーナー、クライアントアプリケーション、認可サーバー、リソースサーバーの4つの主要なロールが関わります。

認可コードグラントの手順は、クライアントアプリケーションがユーザーを認可サーバーにリダイレクトし、ユーザーが認可を行った後、認可コードを受け取り、それをベースにアクセストークンを取得する、といった流れになります。別のウィンドウ(ポップアップ)が開かれるのが特徴です。

また、API管理ツールのApidogでは、OAuth 2.0の認可コードグラントをはじめ、様々な認可フローに対応しています。アクセストークンの自動取得と、APIリクエストへの自動追加が可能なため、OAuth 2.0の認証を簡単に行えるメリットがあります。Apidogを活用することで、開発者はOAuth 2.0の認証を効率的に実装できます。

Apidogのニュースレターを購読する

今すぐ購読すると、いつでもApidogから更新情報と最新観点を手に入れることができます。