【初学者向け】Two-legged OAuth / OAuth 2.0について

はじめに

業務で外部アプリケーションとAPI連携する機能実装を担当したので、
今回は、「Two-legged OAuth」と「OAuth 2.0」についてまとめてみました。

Two-legged OAuth

Two-legged OAuthは、クライアントアプリケーション（自身のアプリケーション）がリソースサーバー（APIサーバー）にアクセスするための認証・認可プロトコルの一つです。

以下の図を用いて、Two-legged OAuthのプロセスを説明します。

         +-------------+       +-----------------+       +---------------+
         |   Client    |       |   OAuth Server  |       |Resource Server|
         +-------------+       +-----------------+       +---------------+
               |                        |                        |
               |   1. Request Token     |                        |
               |----------------------->|                        |
               |                        |                        |
               |    2. Access Token     |                        |
               |<-----------------------|                        |
               |                                                 |
               |               3. Access Resource                |
               |------------------------------------------------>|
               |                                                 |
               |               4. Provide Resource               |
               |<------------------------------------------------|
               |                                                 |

手順の説明

1. トークンのリクエスト:
   クライアントアプリケーションはOAuthサーバーに対して、アクセストークンのリクエストを行います。このリクエストにはクライアントIDとクライアントシークレットが含まれます。

2. アクセストークンの発行:
   OAuthサーバーはクライアントアプリケーションの認証情報を確認し、正当なリクエストであればアクセストークンを発行します。このアクセストークンはクライアントに返されます。

3. リソースへのアクセス:
   クライアントアプリケーションは取得したアクセストークンを使用して、リソースサーバーに対してリソースへのアクセスをリクエストします。このリクエストにはアクセストークンが含まれます。

4. リソースの提供:
   リソースサーバーはアクセストークンを検証し、正当なトークンであれば、要求されたリソースをクライアントアプリケーションに提供します。

Two-legged OAuthの特徴

• ユーザーの関与が不要:
  Two-legged OAuthでは、特定のリソース所有者（ユーザー）が関与しないため、ユーザーの認証や同意が必要ありません。
• サービス間通信:
  主にサーバー間の通信や、サービスとサービスの間のAPI呼び出しに利用されます。
• シンプルなフロー:
  ユーザー認証を含まないため、OAuthの中でもシンプルなフローです。

OAuth 2.0

OAuth 2.0は、リソース所有者（ユーザー）がサードパーティアプリケーションにアクセス権を付与するための認可フレームワークです。セキュリティが高く、クライアントとリソースサーバーが異なるエンティティである場合によく使用されます。

OAuth 2.0のプロセスは下記のとおりです。

       Application           (ex. Google, Facebook)            (APIサーバー)
     +-------------+         +--------------------+         +---------------+
     |   Client    |         |Authorization Server|         |Resource Server|
     +-------------+         +--------------------+         +---------------+
           |                           |                            |
           |  1.Authorization Request  |                            |
           |-------------------------->|                            |
           |                           |                            |
           |   2.Authorization Code    |                            |
           |<--------------------------|                            |
           |                           |                            |
           |      3.Token Request      |                            |
           |-------------------------->|                            |
           |                           |                            |
           |      4.Access Token       |                            |
           |<--------------------------|                            |
           |                                                        |
           |                 5.Resource Request                     |
           |------------------------------------------------------->|
           |                                                        |
           |                 6.Protected Resource                   |
           |<-------------------------------------------------------|
           |                                                        |

手順の説明

1. 認可リクエスト (Authorization Request):
   クライアントアプリケーションがリソース所有者（ユーザー）を認可サーバーにリダイレクトし、認可コードを要求します。
   このリクエストには、クライアントID、リダイレクトURI、レスポンスタイプ（code）、および要求されるスコープが含まれます。

2. 認可コード (Authorization Code):
   ユーザーが認可サーバーで認証し、アクセスを承認すると、認可サーバーはクライアントアプリケーションのリダイレクトURIに認可コードを送信します。

3. トークンリクエスト (Token Request):
   クライアントアプリケーションは、認可コードを使用して認可サーバーからアクセストークンを要求します。
   このリクエストには、クライアントID、クライアントシークレット、認可コード、リダイレクトURI、およびグラントタイプ（authorization_code）が含まれます。

4. アクセストークン (Access Token):
   認可サーバーはリクエストを検証し、正当であればアクセストークンを発行し、クライアントアプリケーションに返します。

5. リソースリクエスト (Resource Request):
   クライアントアプリケーションは、取得したアクセストークンを使用してリソースサーバーに保護リソースへのアクセスを要求します。

6. 保護リソース (Protected Resource):
   リソースサーバーはアクセストークンを検証し、正当であれば要求された保護リソースをクライアントアプリケーションに返します。

OAuth 2.0のメリット

• セキュリティ:
  アクセストークンがクライアントのフロントエンドに直接露出せず、より安全です。
• 柔軟性:
  様々なデバイスやプラットフォームで使用可能です。
• ユーザーフレンドリー:
  パスワードを共有せずに、第三者アプリケーションにアクセス権を与えることができます。

【補足】Refresh Token

Refresh Token（リフレッシュトークン）は、OAuth 2.0認証フレームワークの一部で、アクセストークンの有効期限が切れた際、新しいアクセストークンを取得するために使用されるトークンです。

リフレッシュトークンは通常、アクセストークンよりも長い有効期間を持ち、ユーザーの再認証を必要とせずにアクセストークンを更新するための手段を提供します。

Refresh Tokenのメリット

アクセストークンを再度取得する際、リフレッシュトークンを利用するほうが
認可コードを再度取得するよりメリットを享受できます。
以下にその理由を詳しく記載します。

メリット

1. ユーザーエクスペリエンスの向上:
   • シームレスな体験:
     リフレッシュトークンを使用すると、ユーザーによる再度認証・認可のプロセス（再ログイン等）を省略できます。バックグラウンドで新しいアクセストークンが自動的に取得されるため、ユーザーの体験を損なうことなく継続的なアプリケーション利用を可能にします。
2. セキュリティの強化:
   • 短期間のアクセストークン:
     リフレッシュトークンは通常、アクセストークンよりも長い有効期間で設定されます。
     アクセストークンの有効期限を短く設定することで、不正利用のリスクを軽減できます。
3. パフォーマンスの向上:
   • ネットワークトラフィックの削減:
     認可サーバーとのやり取りを減らし、ネットワークトラフィックを削減できます。
   • サーバー負荷の軽減:
     頻繁に認可サーバーがユーザー認証を行う必要がないため、サーバー負荷を軽減できます。

まとめ

Two-legged OAuth

Two-legged OAuthは、ユーザーの関与を必要としないため、マイクロサービスアーキテクチャや社内システムのAPI統合等のサービス間での安全な通信において非常に有効です。

OAuth 2.0

OAuth 2.0は、セキュリティとユーザビリティを両立させた認可プロトコルであり、多くの現代のWebアプリケーションやサービスで広く使用されています。