25

古い Google openid では、(以前にアプリにオプトインした) ユーザーを認証 URL に送信すると、すぐにアプリにリダイレクトされました。

現在、OAuth2 では、認証 URL がユーザーに許可を求め続けています。これに関するいくつかのドキュメントを読みましたが、得られないのは、このフローがどのように機能するかです:

  1. ユーザーがアプリ経由で Google にログインし、アクセス許可の [許可] をクリックします
  2. 数日後、Cookie がクリアされ、ユーザーがサイトに戻ってきて、[Google にログイン] をクリックします。
  3. ユーザーは再度許可を求められることはなく、すぐにログインされます。

ステップ1で認証トークンまたはリフレッシュトークンを保存することと関係があると思いますが、ステップ3では、それらが誰であるかがわからないため、適切な認証トークンまたはリフレッシュトークンと照合して有効なトークンを取得するにはどうすればよいですかアクセストークン。

私のテストでは、手順 1 で元の認証 URL に送信すると、再度アクセス許可を求められます。

編集：解決策を見つけました

google-api は、認証 URL を作成するときに、デフォルトで「approval_prompt=force」を設定します。

4

4 に答える 4

26

はい、ご指摘のとおり、 approval_prompt=forceURL パラメーターを使用すると、毎回ユーザーに認証ダイアログが強制的に表示されます。この URL パラメーターを削除するだけで、以降の認証フローでユーザーにプロンプ​​トが表示されなくなります。

response_type=codeサーバー側フロー ( ) とオフライン アクセス ( )を使用した場合、得られる応答にはわずかな違いがありますaccess_type=offline。ユーザーが最初に承認するとき (承認画面が表示されたとき)、または を使用してこれを強制したapproval_prompt=force場合は、認証コードを交換するときに と が付与されrefresh_tokenますaccess_token。

ただし、ユーザーが承認画面に表示されないたびに (approvement_prompt=force を使用しない場合の後続の認証)、認証コードを交換すると、access_token のみが付与され、refresh_token は付与されません。したがって、それが使用しているフローであり、オフラインでユーザーのデータにアクセスできるようにする場合は、refresh_token を初めて取得したときに将来使用できるようにローカルに保存する必要があります。

これは、認証データ以外の別のタイプのデータへのアクセスをリクエストした場合にのみ発生する可能性があります (OAuth 2 フローを使用すると、他のデータへのアクセスをリクエストできます。たとえば、Contacts API データ、Calendar API データ、Drive データなど)。 ...) 通常、通常の Open ID フローではオフライン アクセスは必要ありません。

于 2012-06-12T19:07:02.633 に答える
0

私にとってはhd（ホストされたドメイン）パラメーターでした。認証 URL から削除した後、認証用に選択するユーザーのリストが表示されました。hdパラメータの詳細はこちらhttps://developers.google.com/identity/protocols/OpenIDConnect#hd-param

于 2017-06-13T16:45:01.953 に答える