Box Developerドキュメント

認証方法

認証方法

Boxには、アプリケーション開発のためのさまざまな認証方法が用意されており、それぞれが異なるユースケースやアプリケーションの種類に対応しています。使用する認証方法に関係なく、基本的な原則が適用されます。ユーザーは、メインのBoxウェブアプリのフロントエンドでコンテンツにアクセスできない場合、別のユーザーになりすまさない限り、APIを使用してコンテンツにアクセスすることはできません。APIエンドポイントの中には、イベントなど、管理者レベルの権限が必要なものもあります。

各種Boxアプリケーションでは、以下の承認方法を使用できます。

Boxアプリケーションの種類OAuth 2.0をサポートしますか?JWTは?クライアント資格情報は?アプリトークンは?
カスタムアプリはいはいはいいいえ
アクセス制限付きアプリいいえはいいいえはい
カスタムスキルいいえいいえいいえいいえ

OAuth 2.0

OAuth 2.0はクライアント側の認証方法で、そのシンプルさからBox APIに対するユーザーの承認で広く使われています。これはオープンスタンダードであり、ユーザーはアプリケーションに対して他のアプリケーション内の自分のデータへのアクセスを許可できるようになります。Boxのクライアント側認証では、Twitter、Facebook、Googleを使用してウェブサイトにログインする仕組みと同様に、ユーザーはアプリからBoxウェブアプリにリダイレクトされるので、そこでログインしてアプリに自分のデータへのアクセスを許可します。たとえば、Boxではコミュニティフォーラムにログインするユーザーに対してこの認証タイプを使用します。

OAuth 2.0はいつ使用すべきですか?

クライアント側認証は、以下に当てはまるアプリに最適な認証方法です。

  • 既存のBoxアカウントを持っているユーザーと連携する
  • ユーザーがBoxを使用していることを認識できるように、ID管理にBoxを使用する
  • アプリケーションのサービスアカウントではなく各ユーザーアカウント内にデータを保存する

Python OAuth 2.0に関する有用なチュートリアルについては、GitHubを参照してください。

JSONウェブトークン (JWT)

JSONウェブトークン (JWT) は、Box APIの最も一般的なサーバー側認証方法です。JWTはオープンスタンダードであり、堅牢なサーバー間認証を実現します。この方法は、カスタムアプリのみに限定されており、エンドユーザーによる操作は必要ありません。適切な権限が付与されているアプリは、企業内の任意のユーザーの代理として操作できるため、強力でシームレスな統合が促進されます。管理者が承認すると、JWTアプリケーションには、デフォルトで、APIコールを行うサービスアカウントが割り当てられます。

JWTはいつ使用すべきですか?

JWTを使用するサーバー側認証は、以下に当てはまるアプリに最適な認証方法です。

  • Boxアカウントを持たないユーザーと連携する
  • 独自のIDシステムを使用する
  • Boxを使用していることをユーザーに認識させたくない
  • ユーザーのアカウントではなくアプリケーションのサービスアカウント内にデータを保存する
  • 公開キーと秘密キーのペアを管理したい

Node JWTに関する有用なチュートリアルについては、Mediumを参照してください。

クライアント資格情報許可 (CCG)

クライアント資格情報許可のアプローチは、サーバー認証に使用され、クライアントIDとシークレットを使用してアプリケーションのIDを検証します。これは、アクセストークンを取得する際にアプリケーションを識別するための安全な方法です。この方法は、ユーザーの関与なしにサーバー間でやり取りする必要があるシナリオで特に便利です。アプリケーションの構成に応じて、アプリケーションのサービスアカウントまたは管理対象ユーザーとして認証できます。管理者が承認すると、CCGアプリケーションには、デフォルトで、APIコールを行うサービスアカウントが割り当てられます。

CCGを使用する場合

JWTを使用するサーバー側認証は、以下に当てはまるアプリに最適な認証方法です。

  • Boxアカウントを持たないユーザーと連携する
  • 独自のIDシステムを使用する
  • Boxを使用していることをユーザーに認識させたくない
  • ユーザーのアカウントではなくアプリケーションのサービスアカウント内にデータを保存する
  • 公開キーと秘密キーのペアを管理したくない

Python CCGに関する有用なチュートリアルについては、Mediumを参照してください。

アプリトークン認証

アプリトークン認証はもう1つのサーバー側認証オプションで、アプリケーションのサービスアカウントに制限されている、有効期間の長い固定のアクセストークンを使用します。この方法は、Box Viewを利用しているアプリケーションに最適で、アプリにそれ自体のアカウントに対するデータの読み取りと書き込みのアクセス権限だけを必要とするシナリオ向けに設計されています。アプリトークン認証を使用すると、アプリケーションは関連付けられているサービスアカウントとして自動的に認証されるため、エンドユーザーによる承認は必要ありません。また、これはAPIエンドポイントのサブセットに制限されます。

アプリトークン認証を使用する場合

アプリトークンを使用するサーバー側認証は、以下に当てはまるアプリに最適な認証方法です。

  • ユーザーモデルがない環境、またはBoxアカウントを持たないユーザーがいる環境で使用する
  • 独自のID管理システムを使用する
  • Boxを使用していることをユーザーに認識させたくない
  • ユーザーのアカウントではなくアプリケーションのサービスアカウント内にデータを保存する

Box Skills

Box Skillsは、Boxにアップロードされたファイルのカスタマイズした処理に使用される独自の種類のアプリケーションです。サードパーティの機械学習サービスを使用してファイルから情報を抽出し、それをメタデータとして適用します。カスタムスキルの認証は、各スキルイベントに備わっている事前承認済みのAPI資格情報によって簡素化されていますが、APIアクセスには制限があります。カスタムスキルでは特定の認証タイプを選択する必要がなく、シンプルさとBoxの機能との直接統合に重点が置かれています。

Box Skillsを使用する場合

Box Skillsを使用するWebhookベースの認証は、以下に当てはまるアプリに最適な認証方法です。

  • サードパーティの機械学習環境で使用する
  • Boxを使用していることをできるだけユーザーに認識させたい
  • 他のプロセスと連携して最終目標を達成する
  • Box Skillをトリガーするファイルだけを処理する

Box Skillsに関する有用なチュートリアル (英語) については、Mediumを参照してください。

スコープ

開発者コンソールでアプリケーションが作成されると、ユーザーはアプリケーションのスコープを設定する必要があります。ユーザーにBox内のファイルやフォルダへのアクセス権限が付与されるしくみと同様、アプリケーションにも、BoxユーザーやBoxを使用する企業に代わって特定のアクションを実行するための独自の権限が付与されます。アプリケーションに対する権限セットの名前を「スコープ」と言います。つまり、アプリケーションのスコープにより、アプリケーションから呼び出すことのできるエンドポイントが決まります。また、このスコープは、アプリケーションのアクセストークンが提供するアクセス権限に反映されます。

ユーザー権限とスコープ

アクションを実行するための適切なスコープがアプリケーションに設定されている場合でも、アクセストークンと関連付けられた、呼び出しを実行するユーザーにはそのアクションを実行するための権限が必要であり、逆の場合も同様であることを理解することが重要です。

たとえば、ファイルを読み取るようにアプリケーションが設定されている場合、アクセスしようとするファイルの読み取り権限が認証済みユーザーにも必要です。

スコープ、トークンの権限、ユーザー権限がどのように連携しているかの詳細については、Boxのセキュリティガイドを参照してください。