すべてのプロダクト
Search
ドキュメントセンター

SuperApp:API 操作を呼び出す際の承認メカニズム

最終更新日:Jan 18, 2025

基本的なルール

開発者が Application Open Platform を使用する場合、次のルールに注意する必要があります。

  • Application Open Platform は、サーバー上の API 操作を呼び出すことによって、開発者にリソースとサービスを提供します。

  • 開発者は、ユーザーから対応する権限が付与された後にのみ、ユーザー情報を読み書きできます。

  • Open Authorization(OAuth)2.0 を使用して、ミニアプリでユーザー情報を読み書きする権限を開発者に付与します。これにより、開発者はユーザーの基本情報とビジネスデータを取得できます。

OAuth 2.0

OAuth 2.0 は、リソース承認に使用される仕様です。OAuth は、リソース承認のための安全でオープンなシンプルな標準を定義します。OAuth を使用してユーザーリソースに対する権限をサードパーティアプリケーションに付与すると、サードパーティアプリケーションはユーザーのアカウントとパスワードを取得することなく、承認された情報を取得できます。

  • OAuth 2.0 は、RESTful API に使用される委任承認フレームワークです。

  • OAuth 2.0 はトークンベースの承認方式であり、アプリケーションはユーザーのパスワードを公開することなく、ユーザーデータへの制限付きアクセスを取得できます。

  • OAuth 2.0 は、認証と承認を切り離します。

OAuth2.0 の用語

OAuth2.0 のシナリオでは、次の用語が一般的に使用されます。

  • サードパーティアプリケーション: サードパーティアプリケーションは、クライアントとも呼ばれます。

  • リソース所有者: リソース所有者はユーザーです。

  • HTTP サービス: リソースサーバーを所有し、ユーザー情報を提供できるサービスプロバイダーです。

  • 承認サーバー: 承認サーバーは、サービスプロバイダーが承認を処理するために提供するサーバーです。

  • リソースサーバー: リソースサーバーは、ユーザーによって生成されたリソースを格納するために使用されるサーバーです。リソースサーバーは、承認サーバーとは異なるロジックノードにデプロイされます。サーバーは同じ物理ノードに配置できます。

  • ユーザーエージェント: ほとんどの場合、ユーザーエージェントはブラウザを指します。

  • クライアントクレデンシャル: クライアントクレデンシャルは、ユーザー認証に使用されるクライアント ID、パスワード、および認証コードです。

  • アクセストークン: アクセストークンは、プロバイダーがユーザーリクエストを受信した後に、承認サービスプロバイダーによって発行されるトークンです。

  • リフレッシュトークン: 既存のトークンをリフレッシュして新しいトークンを取得できます。トークンは短期間で期限切れになります。トークンの期限が切れると、新しいトークンを取得するために実行する必要があるプロセスは複雑になります。ユーザーエクスペリエンスを向上させるために、トークンをリフレッシュして新しいトークンを取得できます。

OAuth 2.0 でサポートされているトークン取得方法

クライアントは、ユーザーから対応する権限が付与された後にのみ、トークンを取得できます。

開発者は、OAuth 2.0 で指定されている次の方法のいずれかを選択して、サードパーティアプリケーションにトークンを発行できます。

  • 認証コード方式: 最も一般的な方法です。トークンのリフレッシュがサポートされています。

  • 暗黙的コード方式: この方法は Web ブラウザ向けに設計されています。トークンのリフレッシュはサポートされていません。

  • パスワード方式: この方法はレガシーシステム向けに設計されています。トークンのリフレッシュがサポートされています。

  • クライアントクレデンシャル方式: この方法は API サービス向けに設計されています。トークンのリフレッシュはサポートされていません。

OAuth を使用した承認手順

ミニアプリのシナリオでは、認証コード方式を使用して、ユーザーリソースに対する権限をサードパーティアプリケーションに付与できます。他の方法と比較して、認証コード方式は最も一般的で安全な方法です。次の図は、ユーザーリソースに対する権限をサードパーティアプリケーションに付与する手順を示しています。

image

次の項目では、OAuth 2.0 に基づいてミニアプリのサービスが担うロールについて説明します。

  • リソース所有者: ミニアプリのユーザーです。

  • リソースサーバー: スーパーアプリのサーバーです。

  • 承認サーバー: このロールはスーパーアプリサーバーによって担われます。

  • HTTP サービス: このロールはスーパーアプリサーバーによって担われます。

  • サードパーティアプリケーション: 加盟店のミニアプリです。

  • ユーザーエージェント: スーパーアプリです。

加盟店に API 操作を呼び出す権限を付与する

次の図は、加盟店に API 操作を呼び出す権限を付与する方法を示しています。

image