APIの認証の違い

Fuji

OAuth2.0とは

OAuth 2.0は、インターネット上での認証と承認のためのオープンスタンダードです。ユーザーが第三者のアプリケーションに自分のアカウント情報を安全に共有することを可能にするフレームワークを提供します。

具体的には、ユーザーが特定のリソースやデータへのアクセスを第三者のアプリケーションに許可する際、そのユーザーのユーザー名やパスワードを第三者に直接提供する代わりに、「アクセストークン」と呼ばれる短期間有効なトークンが使用されます。これにより、ユーザーの認証情報の漏洩リスクを減らし、より安全にサービスを利用することができます。

OAuth 2.0のプロセスは大まかに以下のような流れになります：

  1. アプリケーションがユーザーにリソースへのアクセス許可を求める。

  2. ユーザーがこのアクセス許可を承認する。

  3. アプリケーションは承認を受けて、「認可サーバー」に対してアクセストークンを要求する。

  4. 認可サーバーがアプリケーションにアクセストークンを発行する。

  5. アプリケーションはこのトークンを使用して、ユーザーが承認したリソースへアクセスする。

このような仕組みにより、ユーザーは自分のプライベート情報を守りつつ、異なるアプリケーション間でデータや機能を安全に共有できるようになります。OAuth 2.0は、多くのWebサービスやアプリケーションで広く採用されています。

オープンスタンダードとは

「オープンスタンダード」とは、特定の個人や組織に制限されず、誰でも利用、実装、改良が可能な技術や仕様のことを指します。オープンスタンダードは、公開されているドキュメントに基づいており、通常はある程度の公的なレビューを経て確立されます。これにより、異なるベンダーや技術間でも相互運用性が保証され、幅広いアプリケーションやサービスでの採用が促進されます。

OAuth 2.0は、その設計と仕様がオープンスタンダードとして開発されており、インターネット工学タスクフォース（IETF）によって公開された一連の文書（RFC 6749およびRFC 6750）によって定義されています。これにより、多くの開発者や企業がOAuth 2.0を基にした認証・承認システムを構築し、様々なアプリケーションやサービスで利用することができるようになっています。

BOX APIの話

サービスアカウントを使用したJWT認証の利点：

  1. 長期間有効なアクセス：JWT認証を使用すると、サービスアカウントを介してBox APIに長期間アクセスできます。これにより、バックグラウンドで実行される自動化されたプロセスに最適です。アプリケーションは、サーバー間の認証で継続的に実行される必要があるタスクに適しています。

  2. 管理者の介入不要：JWT認証を使用する場合、一度設定を行えば、ユーザーが手動でログインする必要がなく、管理者が定期的に介入する必要もありません。これは、自動化されたシステムにとって理想的な環境を提供します。

  3. アプリケーション専用の独立したアカウント：サービスアカウントはアプリケーション専用のアカウントであり、開発者やエンタープライズ管理者の個人アカウントとは独立しています。ファイルの管理と操作はこのアカウント内で行われるため、顧客のデータを組織の他の部分から隔離できます。

  4. 高度なセキュリティ：JWT認証では、秘密鍵を使用してトークンを安全に署名し、これにより認証プロセスのセキュリティが強化されます。サーバーとBox API間の安全な通信を保証するため、自動化プロセスの信頼性が向上します。

実装の概要：

JWT認証を使用してサービスアカウント経由でBox APIにアクセスするためには、次のステップに従います：

  1. Box Developer Consoleでアプリケーションを作成：新しいBoxアプリケーションを作成し、JWT認証を選択します。

  2. 公開鍵/秘密鍵ペアの生成：アプリケーションの認証に使用される鍵ペアを生成します。

  3. エンタープライズIDの取得：Boxアカウントの管理者からエンタープライズIDを取得し、アプリケーションに関連付けます。

  4. アプリケーションの認証設定：生成した秘密鍵、公開鍵、エンタープライズIDを使用して、アプリケーションの認証を設定します。

  5. SDKを使用した開発：Box SDKを使用して、指定されたフォルダからファイルを自動的に取得するプログラムを開発します。

この認証方法を選択することで、自動化されたプロセスの開発と維持が容易になり、顧客がアップロードしたファイルへの安全かつ効率的なアクセスが可能になります。

従来の3レグのOAuth2認証

  • ユーザーの介入が必要：3レグのOAuth2では、エンドユーザーが自身のBoxアカウントでログインし、アプリケーションへのアクセスを承認するプロセスが必要です。自動化システムでは、定期的なユーザーの手動介入を避けるべきですが、この認証方法ではそれが求められます。

  • トークンの期限切れと更新：取得したアクセストークンは有効期限があり、定期的に更新する必要があります。自動化されたプロセスでは、トークンの更新処理を自動で行う追加のロジックが必要になりますが、それにはさらに複雑なコーディングが必要となります。

クライアントクレデンシャルグラント（CCG）

  • エンドユーザーに基づく操作が限定的：CCGは、エンドユーザーではなく、アプリケーション自体の認証に適しています。顧客がアップロードするファイルにアクセスする場合、顧客のアカウントに基づく操作を行う必要があるため、この方法だけでは不十分な場合があります。

  • 一部のAPI機能への制約：CCGで取得したアクセストークンは、アプリケーション自体の権限に基づいています。そのため、特定のユーザーアカウントに関連する詳細な操作には適さない可能性があります。

Box Viewのアプリトークン

  • 長期間のトークンに関する制約：Box Viewのアプリトークンは長期間有効ですが、これらのトークンは自動的に更新されません。システムが長期間にわたって安定して動作させるためには、トークンの期限が切れた場合に手動で更新する必要があり、自動化プロセスには適していません。

  • 特定の用途に限定：アプリトークンは主にBox View APIの利用を目的としています。ファイルのアップロードやダウンロードなど、Boxの全範囲にわたるAPI操作には対応していないため、要件によってはこの認証方法が制限的になる可能性があります。

結論

これらの認証方法は、ユーザーの手動介入の必要性、トークン更新の複雑性、権限の制限など、自動化されたバックグラウンドプロセスの要件に完全には適合しない可能性があります。JWT認証はこれらの課題を解決し、自動化されたサービスアカウントを介した安定したアクセスを提供するため、このような用途に最適な選択肢です。


  • エンドユーザーが自分のBoxアカウントを使用してファイルのダウンロードやアップロードを行う場合    ：

    • このシナリオでは、従来の3レグのOAuth2認証が最適です。ユーザーが自分のBoxアカウントでログインし、アプリケーションへのアクセスを承認することで、アプリケーションがユーザーのアカウントに代わってファイル操作を行えるようになります。この方法は、ユーザーのデータにアクセスするための明確な許可と透明性を提供し、ユーザーエクスペリエンスを向上させることができます。

  • アプリケーションが裏側で自動的にファイル操作を行い、エンドユーザーが特定のユーザーまたはサービスアカウントのファイルにのみアクセスする場合：

    • このシナリオでは、サービスアカウントを使用したJWT認証が適しています。サービスアカウントは、アプリケーション専用のアカウントであり、一度設定すればエンドユーザーがBoxにログインすることなく、裏側でファイル操作を自動化できます。これは、アプリケーションがバックグラウンドで継続的に実行される必要がある場合や、エンドユーザーが直接Boxアカウントにアクセスする必要がない場合に適しています。

この記事が気に入ったらサポートをしてみませんか？