WeChat公式アカウントWebページの承認

はじめに：

ユーザーがWeChatクライアントでサードパーティのWebページにアクセスすると、パブリックアカウントはWeChat Webページの承認メカニズムを通じてユーザーの基本情報を取得できるため、ビジネスロジックを実装できます。

ドメイン名認証コールバックドメイン名に関する注意

1. WeChat公式アカウントからユーザーのウェブページ認証をリクエストする前に、開発者は、パブリックプラットフォームの公式ウェブサイトにある[開発-インターフェース権限-Webサービス-Webサービス-Webアカウント-ユーザー認証を取得するためのWeb認証]設定オプションに移動して、認証コールバックドメインを変更する必要があります。。ここでは、URLではなくドメイン名（文字列）が入力されるため、http：//およびその他のプロトコルヘッダーは追加しないでください。

2.認証コールバックドメイン名の構成仕様は完全なドメイン名です。たとえば、Webページ認証を必要とするドメイン名は次のとおりです：www.qq.com、構成後、このドメイン名の下のページhttp://www.qq.com/music.html、http：// www.qq.com/login.htmlはOAuth2.0認証を実行できます。ただし、http：//pay.qq.com、http：//music.qq.com、http：//qq.comはOAuth2.0認証を実行できません

3.公式アカウントのログイン認証をサードパーティの開発者に与えて管理する場合、設定を行う必要はなく、サードパーティが公式アカウントを差し替えてウェブページ認証を実装することができます。

Webページ認証の2つのスコープの違いについて

1.スコープとしてsnsapi_baseで開始されたWebページ認証は、ページを入力するユーザーのopenidを取得するために使用され、サイレント認証され、コールバックページに自動的にジャンプします。ユーザーが認識するのは、コールバックページ（多くの場合、ビジネスページ）に直接入ることです。

2.スコープがsnsapi_userinfoで開始されたWebページの承認は、ユーザーの基本情報を取得するために使用されます。ただし、このような認証はユーザーが手動で同意する必要があり、ユーザーが同意しているため、ユーザーの基本情報は認証後に心配なく取得できます。

3.ユーザー管理インターフェースの「ユーザー基本情報の取得インターフェース」は、ユーザーがメッセージインタラクションまたはイベントプッシュの後に公式アカウントと対話した後にのみ、ユーザーのOpenIDに従ってユーザー基本情報を取得します。他のWeChatインターフェイスを含むこのインターフェイスでは、ユーザー（openid）が正常に呼び出される前にパブリックアカウントに注意を払う必要があります。

Webアクセスauthorization_tokenと通常のaccess_tokenの違いについて

1. WeChat Webページ認証はOAuth2.0メカニズムを介して実装されます。ユーザーがパブリックアカウントを認証した後、パブリックアカウントはWebページ認証用の一意のインターフェイスコール資格情報（Webページ認証access_token）を取得でき、認証後のインターフェースはWebページ認証によって実行できます基本的なユーザー情報の取得などの呼び出し。

2.他のWeChatインターフェースの場合、基本サポートの「get access_token」インターフェースを介して通常のaccess_token呼び出しを取得する必要があります。

UnionIDメカニズムについて

1.基本的なユーザー情報を取得するためのWebページ認証も、UnionIDメカニズムに従っていることに注意してください。つまり、開発者が複数のパブリックアカウント間、またはパブリックアカウントとモバイルアプリケーション間でユーザーアカウントを統合する必要がある場合、UnionIDを使用する前に、WeChatオープンプラットフォーム（open.weixin.qq.com）にアクセスしてパブリックアカウントをバインドする必要があります。上記のニーズを満たすメカニズム。

2. UnionIDメカニズムの役割の説明：開発者が複数のモバイルアプリケーション、Webサイトアプリケーション、およびパブリックアカウントを持っている場合、同じユーザーが同じWeChatを開いているため、ユーザーの基本情報のunionidを取得することにより、ユーザーの一意性を区別できます。さまざまなアプリケーション（モバイルアプリケーション、Webアプリケーション、パブリックアカウント）、ユニオンIDは同じです。

特別なシナリオでのサイレント認証について

1.上記のように、スコープとしてsnsapi_baseを使用したWebページ認証では、ユーザーの認識なしにサイレント認証されます。

2.公式アカウントに注意を払ったユーザーの場合、公式アカウントセッションまたはカスタムメニューから公式アカウントの公式ページにアクセスすると、スコープがsnsapi_userinfoであっても、サイレント認証であり、ユーザーには認識されません。

具体的には、Webページの承認プロセスは4つのステップに分かれています。

1.承認ページにユーザーを誘導し、承認に同意してコードを取得します

2.コードを介したaccess_tokenのコードの交換（基本サポートのaccess_tokenとは異なります）

3.必要に応じて、開発者はWebページの承認access_tokenを更新して、有効期限を回避できます。

4. Webページ認証access_tokenおよびopenid（UnionIDメカニズムをサポート）を通じて基本的なユーザー情報を取得します。

ディレクトリ

1ステップ1：ユーザーはコードを承認して取得することに同意する

2 2番目のステップ：Webページ認証のためにaccess_tokenのコードを交換します

3ステップ3：access_tokenを更新する（必要な場合）