問題タブ [openid-connect]

Google の OpenID Migration Guideでは、OpenID 2.0 から OpenID Connect に移行するためのステップ 1 で、アプリケーションの OAuth 資格情報を取得する必要があります。

「通常の」OpenID について私が気に入っていることの 1 つは、ユーザーが選択した任意の IDP から認証できることです。Google、Yahoo、またはその他のエンドポイントを使用しているかどうかに関係なく、開発者として、これらの各プロバイダーから OAuth 資格情報を手動で取得し、それらをサポートするようにアプリケーションを構成するという面倒な作業を行う必要はありません。

プロバイダーが従来の OpenID のサポートを終了したため、ユーザーが現在の IDP を引き続き使用できるようにする方法はありますか?

私は e コマース Web サイトを運営しており、Web サイトをよりアクセスしやすくしたいと考えています。そのため、ソーシャル メディア プロファイルの一部を使用してログインできるように、OAuth を使用することを考えています。私はまた、電子メールやその他の方法で顧客に多くのマーケティング キャンペーンを送信します。そのため、ユーザーがサインアップした時点で、電子メールや職業に関する詳細 (製品に関連するものではありません) などの情報が得られます。私がおせっかいではないのでご心配なく！）。

ユーザーが OAuth を使用してサインインする場合、サインアップ フォームを使用する必要がないため、電子メールなどの基本的な情報の一部を私に提供することはありません。

では、OAuth を実装するときに、ユーザーに関してデータベースに保存できるデータを知りたいですか? 現時点では、たとえば、私のウェブサイトのすべてのユーザーにニュースレターを送信できますが、OAuth を使用すると、このようなことは可能ですか? ユーザーが OAuth を使用してサインインしている場合、ユーザーごとにどのような情報にアクセスできますか?

これらの質問が他の場所で回答されている場合は申し訳ありません。検索しようとしましたが、会社が得られるものについて何も見つかりませんでした。基本的なコーディングの観点とユーザーの観点からの長所と短所しか見つけられませんでした。ビューの。

ありがとう！

Web アプリケーションに Google ログインを追加するために Google が提供するオプションを評価しています。私が見るように可能なオプションは

1. Google+ ログイン
2. OAuth2.0
3. OpenID Connect (ログイン用 OAuth2.0 )

1日に実行できるAPI呼び出しが10000に制限されるため、最初のものは使用しませんでした

2と3のうち、私は3番目に行く傾向があります。私は実際には API 承認を必要とせず、私の場合はアクセス トークンの有効期限について心配していません。Google からユーザー プロファイルを受け取ると、Web アプリは独自のユーザー セッションを管理し、ユーザーに関連するその他のデータについて Google にクエリを実行する必要がなくなります。Google のドキュメントによると、#3 ではユーザーの同意画面をカスタマイズできますが、1 と 2 ではできません。

2 と 3 の比較について何かコメントはありますか?

現在、ネイティブ モバイル アプリケーションを開発しており、システム内のリソースを消費するために、ID サーバー (thinktecture ID サーバー v3 で作成) および/または外部のソーシャル ID プロバイダーでエンド ユーザーを認証する必要があります。

OIDC を使用して、アクセス トークンと ID トークンを取得しようとしています。完璧な世界では、エンド ユーザーがログオフすることを決定するまで、ネイティブ モバイル アプリケーションのエンド ユーザーが(ネイティブ アプリの再起動後も) 無期限にログに記録されたままになることを望んでいます。

まず、暗黙的なフローを選択しました。しかし、このフローでは更新トークンを使用できないことがわかりました。

1. 暗黙的なフロー仕様がリフレッシュ トークンを禁止するのはなぜですか? 危険はどこですか？

2. 言い換えれば、トークン エンドポイントが暗黙的フローで「到達可能」でないのはなぜですか?

次に、ハイブリッド フローをテストして、更新トークン (非常に長期間有効ですが取り消し可能) とアクセス トークン (有効期間が短い) を取得しました。問題は、client_secret をネイティブのパブリック クライアントに埋め込むことです。(OIDC 仕様で説明されているように、不適切で安全でない慣行)

3) では…ネイティブ パブリック アプリはハイブリッド フローを使用できません…ですね。

そのため、現在、カスタム コード フロー ソリューションが良いアイデアであるかどうか疑問に思っています。独自のセキュリティで保護された client_secret を使用してトークン エンドポイントに到達できる「プロキシ」/「フロントエンド」Web API を作成し、コード/ネイティブ クライアント アプリから認可サーバー トークン エンドポイントへの refresh_token/access_token リクエスト?

カスタム コード フロー図

4) これについて何かコメントはありますか?

Appengine/Java の使用

私は OpenID 2.0 を OpenID Connect (ログイン用の OAuth 2.0) に移行しています。

ステップ 3: (既存の) OpenID 2.0 識別子を (新しい) OpenID Connect 識別子にマップします。

「ユーザー データベースで、openid_id を新しいサブ ID にリンクしてください」と表示されます。問題は、既存のユーザー テーブルのように、openid_id で既存のユーザーを選択できないことです。ユーザーを識別する値として com.google.appengine.api.users.User.getUserId() が使用されます。

(完全な com.google.appengine.api.users.User オブジェクトも永続化しました)

openid_id を使用して appengine ユーザーを選択する方法はありますか?