web-dev-qa-db-ja.com

OpenID対OpenID Connectを使用するのはいつですか

一緒に使用できますか？ ....または、状況に応じて役立つ場合とそうでない場合のある2つの別々のプロトコルですか？

私が尋ねる理由は、私が以下を実装しようとしているためです：

  1. ユーザー「ボブ」は、ユーザーエージェントのみのアプリケーションとして実装されたクライアントに行きます。
  2. 保護されたリソースは、認証/許可サーバーと同じドメインによって制御されますが、それらは異なるサブドメインにあります。ただし、Cookieにセッションが見つからないため、...

  3. ボブは「ログイン」をクリックし、次のようなものを使用して認証/認証サーバーにリダイレクトされます。

    GET https://accounts.example.com/authorize?response_type=token&client_id=123&redirect_uri=http://original.example.com&scope=openid profile token custom

  4. Bobには、認証するために選択するオプションのリストが与えられます。つまり、「example、google、Twitter」などです。これにより、example.comでの認証につながり、exampleによってホストされている特定のAPIの承認に使用されます。 .com。

OpenID Connect、OpenID 2.0の両方を使用する必要がありますか？何？これらのいずれかを実装するのは初めてです。私はこれの認証部分についてのみ尋ねています。クライアントへのトークンの発行に進むことができるように、ボブの認証を取得しようとしています。

authenticationoauthauthorizationopenidopenid-connect
26
tjb1982

OpenIDとOpenID Connectはどちらもauthentication用であり、authorization用ではありません。 2つのアクティビティは異なります。 OpenID Connectは、実際にはOAuth（認証プロトコル）であり、認証プロトコルに変換（悪用）されています。詳細は この回答 を参照してください。

ある程度、認証と承認を混在させることができますが、それは混乱の元です。あなたのケースでは、明らかに「authenticateusers with "Google、Twitter、...」：Google（またはTwitter）に誰に知らせるかユーザーはですが、ユーザーに許可する必要があるものではありません ;これらの外部プロバイダーには、認証ではなく認証が必要です。

それを確認する別の方法は次のとおりです。ユーザーがサーバーに接続します[〜＃〜] s [〜＃〜]。サーバー[〜＃〜] s [〜＃〜]はいくつかの「サービス」を提供します。つまり、要求されたときに「もの」を実行します。ただし、誰もが同じことをすることは認められません。 [〜＃〜] s [〜＃〜]が各ユーザーに対して別のユーザーに何をするかしないかを制御するのに適していると思ったとしましょう呼び出すシステム[〜＃〜] r [〜＃〜]。 [〜＃〜] r [〜＃〜]は[〜＃と同じコンピューターである場合と同じでない場合があります〜] s [〜＃〜]、しかし一般的に考えて[〜＃〜] r [〜＃〜]は[〜＃〜] s [〜＃〜]とは異なります。 [〜＃〜] s [〜＃〜]の観点から、必要な情報は承認の範囲内にあります：[〜＃〜] s [〜＃〜]は、コールが許可されるかどうかを知りたいと考えています。したがって、[〜＃〜] s [〜＃〜]と[の間でいくつかの認証プロトコルが実行されます〜＃〜] r [〜＃〜]。おそらく、[〜＃〜] s [〜＃〜]および[〜＃〜] r [〜＃ 〜]は、互いに直接通信するのではなく、クライアントによって転送されるメッセージ（「チケット」）を介してのみ通信します。それは技術的な詳細です。

ただし、[〜＃〜] s [〜＃〜]への特定のリクエストを許可するかどうかを決定するには、認証サーバー[〜＃〜] r [〜＃〜]はwhoが答えはユーザーのIDに依存するためです。したがって、[〜＃〜] r [〜＃〜]はユーザーを認証する必要があります。または、より一般的には、認証サーバーと通信する[〜＃〜] t [〜＃〜]。 [〜＃〜] t [〜＃〜]は、ユーザーが本当に本人であることを確認する責任があります。次に、認証プロトコルが[〜＃〜] r [〜＃〜]と[〜＃〜]の間で発生しますt [〜＃〜]。

あなたの例では、[〜＃〜] r [〜＃〜]が認証サーバーであり、[〜 ＃〜] t [〜＃〜]はGoogle/Twitterです。 [〜＃〜] r [〜＃〜]と[〜＃〜] tの間でOpenIDを使用します[〜＃〜]、およびOAuth between[〜＃〜] s [〜＃〜]および[〜＃〜] r [〜＃〜]。

OpenID Connectは、[〜＃〜] s [〜＃〜]が何らかの認証も実行したい場合です。 [〜＃〜] s [〜＃〜]次に[〜＃〜] r [〜＃〜 ]（だれが「OAuthを話す」）かを推測します[〜＃〜] r [〜＃〜]リクエストを許可する場合、[〜＃〜] r [〜＃〜]がユーザーの何らかの認証を行っている必要があります。したがって、[〜＃〜] s [〜＃〜]は、（暗黙的に）確信しているため、ユーザーが確かに誰であるかを決定します[〜＃〜] r [〜＃〜]。

19
Thomas Pornin

他の以前の応答のいずれも、OpenID ConnectとOpenID 2.0の違いを尋ねる質問に答えるとは思わない。 OpenID 2.0はOAuth 2.0ではありません。

OpenID 2.0とOpenID Connectは、まったく異なるパラメーターであり、応答本文の形式がまったく異なります。どちらもOAuth 2.0の上に構築されており、認証に必要なID情報を提供するために、他の場合は有効なOAuth 2.0リクエストとレスポンスに追加の値を入れます（一方、OAuth 2.0は認証のみでなく承認のみを提供します）。 。 OpenID Connectは、OpenID 2.0フィールドとパラメーターの命名と構造を改善し、使いやすくしました。私はOpenID Connect仕様を簡単に読み、すべての値が何に使用され、それらに何を設定するかを理解できますが、OpenID 2.0仕様を読むのは少し難しく複雑です。

この時点で選択は簡単です。OpenID 2.0は非推奨です。 OpenID Connectを使用してください。

25
theferrit32

OAuthは、アクセストークンを使用した認証のみを提供します。 OpenID接続は、ユーザー認証情報を提供するためにOAuth 2に基づいて構築されています。OpenID接続は、実際にはOpenIDの子です。 OpenID-Connect-Lecture-for-MITを参照してください、スライド

OpenID Connect 1.0は、OAuth 2.0 [RFC6749]プロトコルの上にあるシンプルなIDレイヤーです。これにより、クライアントは、承認サーバーによって実行された認証に基づいてエンドユーザーのIDを確認できます。エンドユーザーに関する基本的なプロファイル情報を相互運用可能なRESTのような方法で取得するOpenID Connect Core 1.0-ドラフト17

OpenID Connectは、ユーザーIDを取得する「標準」の方法を提供します。 OAuthとAPIを使用する場合は、各リソースにリクエストを適合させる必要があります。これにより、常に同じ情報が提供されるとは限らないか、時間とともに変化する可能性があります。概念的には、OAuth APIの使用が許可され、ユーザーの認証は許可されません。

背景として、OAuth 2.0 Authorization Framework [RFC6749]およびOAuth 2.0 Bearer Token Usage [RFC6750]仕様は、サードパーティアプリケーションが取得する一般的なフレームワークを提供しますHTTPリソースへの制限付きアクセスを使用します。リソースにアクセスするためのアクセストークンを取得および使用するメカニズムを定義しますが、ID情報を提供する標準メソッドを定義しません。特に、プロファイリングなしでOAuth 2.0、それは不可能ですユーザーの認証に関する情報を提供する方法OpenID Connect Core 1.0-ドラフト17

OpenID connectは、ユーザーに関するいくつかの情報をid_tokenに提供することに注意してください。しかし、すべての情報が必要な場合でも、OpenIDプロバイダーにuserinfoを取得するように要求するためのaccess_tokenが必要です（これは、初めて表示されたときに混乱します）。見る 5.3.1. userinfo requestドラフト

5
Nereis