私は本当に OpenID と OAuth の違いを理解しようとしていますか? たぶん、それらは2つの完全に別のものですか？
質問する
302243 次
21 に答える
910
OpenIDは認証に関するものであり (つまり、あなたが誰であるかを証明する)、OAuthは承認に関するものです (つまり、元の認証を処理することなく、機能/データ/などへのアクセスを許可すること)。
外部のパートナー サイトで OAuth を使用して、ユーザーを再認証することなく保護されたデータにアクセスできるようにすることができます。
ブログ投稿「ユーザーの観点から見た OpenID と OAuth」には、ユーザーの観点から見た 2 つの単純な比較があり、「OAuth-OpenID: You're Barking Up the Wrong Tree if you think They're the same Thing」には詳細情報があります。それについて。
于 2009-07-06T13:47:07.407 に答える
397
OAuth と OpenID を比較するには、次の 3 つの方法があります。
1. 目的
OpenID はフェデレーション認証用に作成されました。つまり、サード パーティが既に持っているアカウントを使用して、ユーザーを認証できるようにします。OpenID の全体的なポイントは、(ホワイトリストを除いて) 任意のプロバイダーを使用できることであるため、フェデレーテッドという用語はここで重要です。ユーザーが他のアカウントを使用できるようにするために、事前にプロバイダーを選択したり、プロバイダーと交渉したりする必要はありません。
OAuth は、ユーザーがパスワードをサードパーティ アプリケーションと共有する必要をなくすために作成されました。実際には、OpenID の問題を解決する方法として開始されました。サイトで OpenID をサポートしている場合、HTTP Basic 資格情報 (ユーザー名とパスワード) を使用して API を提供することはできません。これは、ユーザーがサイトでパスワードを持っていないためです。
問題は、認証用の OpenID と認可用の OAuth をこのように分離することで、両方のプロトコルが同じことの多くを達成できることです。それらはそれぞれ、異なる実装で必要とされる異なる機能のセットを提供しますが、基本的にはかなり互換性があります。基本的に、両方のプロトコルはアサーション検証方法です (OpenID は「this is who I am」アサーションに限定されますが、OAuth は API を介してサポートされているアサーションと交換できる「アクセス トークン」を提供します)。
2.特徴
どちらのプロトコルも、サイトがユーザーを別の場所にリダイレクトし、検証可能なアサーションを返す方法を提供します。OpenID は ID アサーションを提供しますが、OAuth はアクセス トークンの形式でより一般的であり、「OAuth プロバイダーに質問する」ために使用できます。ただし、それぞれ異なる機能をサポートしています。
OpenID - OpenID の最も重要な機能は、その検出プロセスです。OpenID では、事前に使用する各プロバイダーをハードコーディングする必要はありません。検出を使用すると、ユーザーは認証するサードパーティ プロバイダーを選択できます。この検出機能は、ほとんどの Web ユーザーが取得できない識別子として HTTP URI を使用して実装されているため、OpenID の問題のほとんどを引き起こしています。OpenID が持つその他の機能には、DH 交換を使用したアドホック クライアント登録のサポート、最適化されたエンドユーザー エクスペリエンスのための即時モード、およびプロバイダーへの別のラウンドトリップを行わずにアサーションを検証する方法があります。
OAuth - OAuth の最も重要な機能は、追加のリクエストを作成する永続的な方法を提供するアクセス トークンです。OpenID とは異なり、OAuth は認証で終了するのではなく、同じサードパーティ サービスによって提供される追加のリソースにアクセスするためのアクセス トークンを提供します。ただし、OAuth は検出をサポートしていないため、使用するプロバイダーを事前に選択してハードコーディングする必要があります。あなたのサイトにアクセスするユーザーは、あなたが事前に選択したものだけを使用して、識別子を使用することはできません。また、OAuth には ID の概念がないため、ログインに OAuth を使用することは、(Twitter で行われているように) カスタム パラメーターを追加するか、別の API 呼び出しを行って現在「ログインしている」ユーザーを取得することを意味します。
3. 技術的な実装
2 つのプロトコルは、リダイレクトを使用してユーザー認証を取得するという共通のアーキテクチャを共有しています。OAuth では、ユーザーは保護されたリソースへのアクセスを承認し、OpenID では ID へのアクセスを承認します。しかし、それは彼らが共有するすべてです。
プロトコルごとに、要求または応答の信頼性を検証するために使用される署名を計算する方法が異なり、それぞれに異なる登録要件があります。
于 2011-08-02T16:37:41.117 に答える
119
OpenID は (主に) 識別/認証用であるため、stackoverflow.com私が (またはどこにでも) 所有していることを認識しているため、おそらく昨日所有して評判ポイントを獲得しchris.boyle.nameたのと同じ人物であることがわかります。chris.boyle.name
OAuth は、ユーザーに代わってアクションを実行する権限を与えるように設計されているためstackoverflow.com、Twitter のパスワードを知らなくても、ユーザーに代わってツイートする許可を (またはどこでも) 自動的に求めることができます。
于 2009-07-06T13:45:08.033 に答える
106
于 2014-05-19T08:37:59.807 に答える
46
OAuth
委任authorizationされた場合にのみ使用されます。つまり、パスワードを提供せずに、個人データを使用するサードパーティ サービス アクセスを許可していることを意味します。また、OAuth の「セッション」は通常、ユーザー セッションよりも長く存続します。OAuth は承認を許可するように設計されていることを意味します
つまり、Flickr は OAuth を使用して、サードパーティ サービスがユーザー名とパスワードを提供することなく、ユーザーに代わって人物の写真を投稿および編集できるようにします。
OpenID
authenticateID のシングル サインオンに使用されます。OpenID が行うことになっているのは、OpenID プロバイダーがあなたが自分であると主張していることを証明できるようにすることだけです。ただし、多くのサイトでは ID 認証を使用して承認を提供しています (ただし、この 2 つは分離できます)。
つまり、空港でパスポートを提示して、使用しているチケットに記載されている名前が本人であることを認証 (または証明) します。
于 2009-07-06T20:15:33.220 に答える
34
ユーザーが Facebook や Twitter でログインしたいだけの場合は、OAuth を使用してください。ユーザーが自分の ID を他の誰かに所有されたくないという理由で独自の OpenID プロバイダーを実行している場合は、OpenID を使用してください。
于 2012-03-20T19:37:06.940 に答える
22
OpenID、OAuth、OpenID Connect の違いの説明:
OpenID は認証用のプロトコルであり、OAuth は承認用のプロトコルです。認証とは、話している相手が本当に本人であることを確認することです。承認とは、その人物に何を許可するかを決定することです。
OpenID では、認証は委任されます。サーバー A はユーザー U を認証しようとしますが、U の資格情報 (U の名前とパスワードなど) は、A が信頼する (少なくとも、ユーザーの認証を信頼する) 別のサーバー B に送信されます。実際、サーバー B は U が実際に U であることを確認してから、A に「OK、それが本物の U です」と伝えます。
OAuth では、承認は委任されます。エンティティ A は、エンティティ B から「アクセス権」を取得します。これは、A がサーバー S にアクセスを許可するために示すことができます。したがって、B は一時的な特定のアクセス キーを A に与えることができます。OAuth サーバーが大きなホテルのキー マスターであると想像できます。彼は従業員に、入るべき部屋のドアを開ける鍵を渡しますが、各鍵には制限があります (すべての部屋にアクセスできるわけではありません)。さらに、キーは数時間後に自己破壊します。
エンティティ A が B から OAuth を介してアクセス キーを取得し、それをサーバー S に示す場合、サーバー S は、アクセスを許可する前に B が A を認証したと推測する可能性があることに基づいて、ある程度、認可を疑似認証に悪用することができます。鍵。そのため、OpenID を使用すべき場所で OAuth を使用する人もいます。このスキーマは啓発的である場合とそうでない場合があります。しかし、この疑似認証は何よりもややこしいと思います。OpenID Connect はまさにそれを行います。OAuth を認証プロトコルに悪用します。ホテルのたとえで言えば、仮に従業員と思われる人に遭遇し、その人が私の部屋を開ける鍵を持っていることを私に示した場合、鍵のマスターが彼に鍵を渡さなかったことに基づいて、これは真の従業員であると思います。彼がいなかった場合、それは私の部屋を開きます。
OpenID Connect は OpenID 2.0 とどう違うのですか?
OpenID Connect は、OpenID 2.0 と同じタスクの多くを実行しますが、API フレンドリーで、ネイティブおよびモバイル アプリケーションで使用できる方法で実行します。OpenID Connect は、堅牢な署名と暗号化のためのオプションのメカニズムを定義します。OAuth 1.0a と OpenID 2.0 の統合には拡張が必要でしたが、OpenID Connect では、OAuth 2.0 の機能がプロトコル自体に統合されています。
OpenID Connect は、アクセス トークンと id トークンを提供します。id トークンは JWT であり、認証されたユーザーに関する情報が含まれています。これは ID プロバイダーによって署名されており、ID プロバイダーにアクセスせずに読み取りと検証を行うことができます。
さらに、OpenID Connect は、oauth2 が選択に任せている多くのことを標準化します。インスタンス スコープ、エンドポイント ディスカバリ、クライアントの動的登録など。
これにより、ユーザーが複数の ID プロバイダーから選択できるようにするコードを簡単に記述できるようになります。
Google の OAuth 2.0
Google の OAuth 2.0 API は、認証と承認の両方に使用できます。このドキュメントでは、OpenID Connect 仕様に準拠し、OpenID 認定を受けている、認証用の OAuth 2.0 実装について説明します。「 OAuth 2.0 を使用して Google API にアクセスする」にあるドキュメント も、このサービスに適用されます。このプロトコルをインタラクティブに調べたい場合は、 Google OAuth 2.0 Playgroundをお勧めします。
于 2016-10-30T20:38:49.317 に答える
21
OpenID と OAuth は、それぞれ認証や承認のための HTTP ベースのプロトコルです。どちらも、クライアントまたはサード パーティに認証資格情報または包括的なアクセス許可を与えることなく、ユーザーがアクションを実行できるようにすることを目的としています。それらは似ており、両方を一緒に使用するための提案された標準がありますが、それらは別個のプロトコルです。
OpenID はフェデレーション認証を目的としています。クライアントは、任意のプロバイダーからの ID アサーションを受け入れます (ただし、クライアントはプロバイダーをホワイトリストまたはブラックリストに登録できます)。
OAuth は、代理承認を目的としています。クライアントは、ユーザーに代わってアクションを実行するために受け入れる承認トークンを提供するプロバイダーに登録します。
OAuth は、認証後のさらなる対話がプロトコルに組み込まれているため、現時点では承認に適していますが、両方のプロトコルが進化しています。OpenID とその拡張機能は認証に使用でき、OAuth は認証に使用できます。これはノーオペレーション認証と考えることができます。
于 2009-08-27T23:27:06.807 に答える
15
コメントでも指摘されているように、この質問を再検討することは理にかなっていると思います.OpenID Connectの導入により、さらに混乱が生じた可能性があります.
OpenID Connect は OpenID 1.0/2.0 のような認証プロトコルですが、実際には OAuth 2.0 の上に構築されているため、認証機能と共に承認機能も利用できます。この 2 つの違いは、この (比較的最近の、しかし重要な) 記事で詳しく説明されています: http://oauth.net/articles/authentication/
于 2015-01-12T11:18:56.067 に答える
11
回答というよりも質問の延長ですが、上記の優れた技術的な回答にいくつかの視点を追加する場合があります。私は多くの分野で経験豊富なプログラマーですが、Web のプログラミングには完全に慣れていません。現在、Zend Framework を使用して Web ベースのアプリケーションを構築しようとしています。
アプリケーション固有の基本的なユーザー名/パスワード認証インターフェイスを実装することは間違いありませんが、増え続けるユーザーにとって、さらに別のユーザー名とパスワードを考えることは抑止力になることを認識してください。正確にはソーシャル ネットワーキングではありませんが、このアプリケーションの潜在的なユーザーのかなりの割合が既に facebook や twitter のアカウントを持っていることを私は知っています。アプリケーションは、これらのサイトからユーザーのアカウントに関する情報に実際にアクセスする必要はありません。ユーザーが望まない場合に新しいアカウントの資格情報を設定する必要がないという利便性を提供したいだけです。機能の観点からは、これは OpenID の見本となるように思えます。しかし、facebook も twitter も、ユーザーのデータにアクセスするための OAuth 認証をサポートしていますが、それ自体は OpenID プロバイダーではないようです。
この 2 つとその違いについて私が読んだすべての記事で、上記の Karl Anderson の観察を見るまでは、「OAuth は認証に使用でき、これはノーオペレーション認証と考えることができます」ということは理解できませんでした。私がやりたいことに対して OAuth で十分であるという明確な確認を見ました。
実際、私がこの「回答」を投稿しようとしたとき、当時はメンバーではなかったので、このページの下部で自分自身を識別するためのオプションをじっくりと調べました。OpenID ログインを使用するか、持っていない場合は取得するオプションがありますが、twitter や facebook については何もありません。OAuth がこの仕事に適していないことを示唆しているように見えました。しかし、別のウィンドウを開いて、stackoverflow の一般的なサインアップ プロセスを探しました。見よ、Facebook や Twitter を含む多数のサードパーティ認証オプションがあります。結局、友人リストへのstackoverflowアクセスを許可したくなかったという正確な理由で、Google ID（OpenID）を使用することにしました。
この種の複数のサードパーティ認証設定のサポートに関する情報や情報へのポインター、および認証を取り消したりサードパーティのサイトへのアクセスを失ったユーザーに対処する方法を誰かが投稿できれば、本当に素晴らしいことです. また、ここでの私のユーザー名は、セットアップしたい場合に基本認証でアクセスできる一意のスタックオーバーフロー アカウントを識別し、他のサードパーティの認証システムを介してこの同じアカウントにアクセスすることもできます (たとえば、ログに記録されていると見なされるようにするため)。 google、facebook、または twitter のいずれかにログインしていた場合は、stackoverflow に...)。このサイトはそれを行っているので、ここにいる誰かがおそらくこの件に関してかなり良い洞察を持っています. :-)
申し訳ありませんが、これは非常に長く、回答というよりも質問でした - しかし、Karl の発言は、OAuth と OpenID に関する大量のスレッドの中で投稿するのに最も適切な場所のように思われました. 私が見つけられなかったより良い場所がある場合は、前もってお詫び申し上げます。
于 2010-10-06T06:41:36.980 に答える
4
OpenIDは、あなたが誰であるかを証明します。
OAuthは、承認者が提供する機能へのアクセスを許可します。
于 2015-12-26T11:41:38.140 に答える
2
読んでいくつかの作業を行った後、知っておく必要があることを理解しました。これらは、OpenID Connect、OAuth、JWT、および SAML です。
私は要約を与えます、それは誰かを助けるかもしれません:
Openid connect(OIDC): Google アカウントを使用して Web サイトにログインできる場合は、OIDC を使用しています。
OAuth : アプリケーションが Facebook の連絡先リストにアクセスして、私の代わりに何らかの処理を実行しようとしています。このアプリケーションを承認する場合、おそらく OAuth を使用しています。
JWT : OAuth は JWT、JWT (JSON Web トークン) を使用します。これは単なるトークン形式です。JWT トークンは、JSON でエンコードされたデータ構造で、発行者、サブジェクト (クレーム)、有効期限などに関する情報が含まれています。改ざん防止と信頼性のために署名されており、対称または非対称アプローチを使用してトークン情報を保護するために暗号化できます。JWT は SAML 1.1/2.0 よりもシンプルで、すべてのデバイスでサポートされており、SWT (Simple Web Token) よりも強力です。
OAuth での承認フロー:
OAuth 2.0 プロトコルは、ユーザーを承認してアクセス トークンを取得するためのワークフローをいくつか提供します。どのフローが最も適しているかは、クライアントのタイプとアーキテクチャによって異なります。
以下は、最もよく使用される 2 つの承認フローです。
- 認証コード:クライアントとサーバー コンポーネントを含むサードパーティの Web サイトに適しています。
- ユーザーは、安全なログイン Web ページに資格情報を入力します。
- ログイン後、ブラウザーは (クライアントによって定義された) 特別な URL にリダイレクトされ、その URL で認証コードが渡されます。
- サードパーティのサーバーは、認証コードを使用して、バックグラウンドで別の HTTP リクエストを使用してアクセス トークンを取得します。https://developers.video.ibm.com/api-basics-authentication/から
- 注: フロントエンド アプリケーションがあり、サーバーがブラウザーに Cookie を設定している場合、ブラウザーには既に Cookie があり、Web サイトにアクセスできます。
- クライアント資格情報:サーバー側アプリケーションを開発してコンテンツや設定を管理するユーザーに最適です。
IBM はここに良いガイドを持っています : https://developers.video.ibm.com/api-basics-authentication oauth-2-0/
SAML : openid の代替としても使用されますが、xml ベースです。開発者は OIDC を使用する方がはるかに簡単で、より柔軟であるため (たとえば、モバイル アプリでの作業は xml ベースの SAML よりも簡単です)、OIDC が勝者になると思われます。
Opnid connect と saml:主な違いがあります。
SAML は、ユーザー データを XML 形式で送信します。OIDC はユーザー データを JSON 形式で送信します。
SAML は、SAML アサーションを送信するユーザー データを呼び出します。OIDC はデータ クレームを呼び出します。
SAML は、ユーザーがサービス プロバイダーにアクセスしようとしているアプリケーションまたはシステムを呼び出します。OIDC はそれを Relying Party と呼んでいます。
SAML は古く、より多くの機能を備えていますが、XML ベースの SAML よりも実装が簡単で使いやすいため、Openid の人気が高まっています。ただし、すべての ID プロバイダーが openid または SAML をサポートしているわけではありません。選択の余地はありません。
SAML よりも多くの openid が必要ですか? 以下を読んでください：
https://www.onelogin.com/blog/real-difference-saml-oidc
https://auth0.com/intro-to-iam/saml-vs-openid-connect-oidc/
もっと欲しい？この Oauth と openid のアナロジーを読むことができます。
http://cakebaker.42dh.com/2008/04/01/openid-versus-oauth-from-the-users-perspective/
于 2021-11-23T21:33:27.703 に答える
-5
OAuth は承認の上に認証を構築します。ユーザーは自分の ID へのアクセスをアプリケーションに委任します。アプリケーションは ID API のコンシューマーになり、最初に誰がクライアントを承認したかを見つけますhttp://oauth.net/記事/認証/
于 2015-10-23T17:58:29.937 に答える