OpenID は認証（つまり、あなたが誰であるかを証明すること）、 OAuth は認証（つまり、元の認証を扱わずに機能/データなどへのアクセスを許可すること）についてです。
OAuthを外部のパートナーサイトで使用して、保護されたデータにユーザーを再認証しなくてもアクセスできるようにすることができます。
ブログ記事「 OpenIDとユーザーの観点からのOAuth 」では、ユーザーの観点から見た2つの単純な比較と「 OAuth-OpenID：あなたが間違ったツリーに吠えている」同じこと "それについてのより多くの情報があります。
OAuthとOpenIDを比較する方法は3つあります。
1.目的
OpenIDは、フェデレーション認証用に作成されました。つまり、サードパーティが既に持っているアカウントを使用してあなたのためにあなたのユーザーを認証させることができます。 OpenIDのポイントは、すべてのプロバイダを使用できるということです（ホワイトリストを除く）ので、ここでは統合という用語が重要です。ユーザーが他のアカウントを使用できるようにするために、プロバイダーとの契約を事前に選択したり交渉する必要はありません。
OAuthは、ユーザーが自分のパスワードをサードパーティのアプリケーションと共有する必要性を排除するために作成されました。それは実際にOpenIDの問題を解決する方法として始まりました。あなたのサイトでOpenIDをサポートしている場合、ユーザーはあなたのサイトにパスワードを持っていないのでAPIを提供するためにHTTP Basicクレデンシャル（ユーザー名とパスワード）を使用できません。
問題は、認証用のOpenIDと認証用のOAuthのこの分離にあります。両方のプロトコルが同じことの多くを達成できるということです。それらはそれぞれ異なる実装で必要とされる異なる機能のセットを提供しますが、本質的に、それらはかなり交換可能です。基本的には、どちらのプロトコルもアサーション検証方法です（OpenIDは「これは私が誰なのか」というアサーションに限定されますが、OAuthはAPIを介してサポートされるアサーションと交換できる「アクセストークン」を提供します）。
2.機能
どちらのプロトコルも、サイトが他の場所にユーザーをリダイレクトし、検証可能なアサーションを返すための方法を提供します。 OpenIDはIDアサーションを提供しますが、OAuthはアクセストークンの形式でより一般的ですが、これを使用して "OAuthプロバイダに質問する" となります。ただし、それぞれ異なる機能をサポートしています。
OpenID - OpenIDの最も重要な機能はその発見プロセスです。 OpenIDでは、事前に使用したいプロバイダをそれぞれハードコーディングする必要はありません。ディスカバリーを使用して、ユーザーは認証したいサード・パーティーのプロバイダーを選択できます。この発見機能はOpenIDの問題の大部分を引き起こしています。なぜなら、それが実装されている方法は、ほとんどのWebユーザがたどり着かない識別子としてHTTP URIを使用することによるからです。その他の機能OpenIDには、DH交換を使用したアドホッククライアント登録のサポート、最適化されたエンドユーザーエクスペリエンスのための即時モード、およびプロバイダーへの往復の必要なしにアサーションを検証する方法があります。
OAuth - OAuthの最も重要な機能は、追加のリクエストを行うための長期的な方法を提供するアクセストークンです。 OpenIDとは異なり、OAuthは認証では終了しませんが、同じサードパーティサービスによって提供される追加のリソースにアクセスするためのアクセストークンを提供します。ただし、OAuthはディスカバリをサポートしていないため、使用するプロバイダを事前に選択してハードコーディングする必要があります。あなたのサイトを訪れるユーザーはあなたが事前に選択したものだけを識別することはできません。また、OAuthにはアイデンティティーの概念がないため、ログインに使用すると（Twitterのように）カスタムパラメータを追加するか、現在「ログイン」しているユーザーを取得するために別のAPI呼び出しを行うことになります。
3.技術的実装
2つのプロトコルは、リダイレクトを使用してユーザー認証を取得する際に共通のアーキテクチャを共有しています。 OAuthでは、ユーザーは自分の保護されたリソースへのアクセスとOpenIDでの自分の身元へのアクセスを承認します。しかし、それが彼らが共有するすべてです。
各プロトコルには、要求または応答の信頼性を検証するために使用される署名の計算方法が異なり、それぞれ登録要件が異なります。
OpenIDは（主に）識別/認証のためのもので、stackoverflow.comは私がchris.boyle.nameを所有していることを（またはどこからでも）知っているので、おそらく私は昨日chris.boyle.nameを所有し、いくつかの評判ポイントを得たのと同じ人です。
OAuthはあなたに代わって行動を取る権限を与えるように設計されているので、stackoverflow.com（またはどこでも）はあなたのTwitterパスワードを知らなくても自動的にあなたに代わってツイートなどの許可を求めることができます。
OAuth
authorizationonly - パスワードを指定せずに、第三者のサービスによるアクセスで個人データを使用することを承認していることを意味します。また、OAuthの "セッション"は一般にユーザーセッションよりも長生きします。 OAuthが承認を許可するように設計されているという意味
つまり、FlickrはOAuthを使用して、第三者のサービスが自分の代わりに人物の写真を投稿および編集できるようにしています。
OpenID
authenticateシングルサインオンID。 OpenIDがするべきことは、OpenIDプロバイダがあなたがあなたがいると言っていることを証明することを許可することだけです。ただし、多くのサイトでは認証を提供するためにID認証を使用しています（ただし、この2つは区別することができます）。
つまり、空港で自分のパスポートを見せて、その人の名前が自分の使っているチケットに記載されていることを証明（証明）します。
ユーザーがFacebookまたはTwitterでログインしたいだけの場合は、OAuthを使用してください。ユーザーが自分のOpenIDプロバイダーを運営している首謀者であれば、OpenIDを使用します。
OpenIDとOAuthはそれぞれ認証および/または承認のためのHTTPベースのプロトコルです。どちらも、認証資格情報や包括的な権限をクライアントや第三者に与えずにユーザーが操作を実行できるようにすることを目的としています。それらは類似しており、両方を一緒に使用するための提案された標準がありますが、それらは別々のプロトコルです。
OpenIDはフェデレーション認証を目的としています。クライアントは、任意のプロバイダからのIDアサーションを受け入れます（ただし、クライアントはホワイトリストプロバイダまたはブラックリストプロバイダに自由にアクセスできます）。
OAuthは委任認証を目的としています。クライアントはプロバイダに登録します。プロバイダは、ユーザーに代わってアクションを実行するために承認トークンを提供します。
OAuthは現在認証に適しています。認証後のさらなる対話がプロトコルに組み込まれていますが、両方のプロトコルが進化しているためです。 OpenIDとその拡張機能は承認に使用でき、OAuthは認証に使用できます。これは何もしない承認と見なすことができます。
コメントでも指摘されているように、この質問を再検討するのは理にかなっていると思います。OpenIDConnectの導入はさらに混乱を招くかもしれません。
OpenID ConnectはOpenID 1.0/2.0のような認証プロトコルですが、実際にはOAuth 2.0の上に構築されているので、認証機能と共に認証機能も利用できます。この2つの違いはこの（比較的最近の、しかし重要な）記事で詳しく詳しく説明されています： http://oauth.net/articles/authentication/ /
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を認証したことを推測することができます。キー。そのため、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であり、認証されたユーザーに関する情報が含まれています。これはアイデンティティプロバイダによって署名されており、アイデンティティプロバイダにアクセスすることなく読み取りおよび検証できます。
さらに、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 をお勧めします。
答えよりも質問への拡張ですが、それは上記の素晴らしい技術的な答えにいくらかの展望を加えるかもしれません。私は多くの分野で経験豊富なプログラマーですが、Webのプログラミングにはまったく興味がありません。 Zend Frameworkを使ってWebベースのアプリケーションを作成しようとしています。
間違いなくアプリケーション固有の基本的なユーザー名/パスワード認証インターフェースを実装するでしょうが、ますます多くのユーザーにとって、さらに別のユーザー名とパスワードの考えが抑止力であることを認識してください。厳密にはソーシャルネットワーキングではありませんが、アプリケーションの潜在的なユーザーの大部分がすでにFacebookまたはTwitterのアカウントを持っていることを私は知っています。このアプリケーションは、これらのサイトからユーザーのアカウントに関する情報にアクセスすることを実際には望まない、または必要としません。ユーザーが望まない場合は、ユーザーに新しいアカウント資格情報の設定を要求しないという利便性を提供するだけです。機能的な観点からは、それはOpenIDのポスターの子になるでしょう。しかし、facebookもTwitterもそれ自体OpenIDプロバイダーではないようですが、ユーザーのデータにアクセスするためのOAuth認証はサポートされていません。
私がこの2つについて読んだすべての記事とそれらがどのように異なるかについて、私が上記のKarl Andersonの観察を見るまで、それは「OAuthは認証に使うことができ、無操作認証と考えることができます」私は、OAuthが私がやりたいことのために十分に良いという明確な確認を見ました。
実際、当時のメンバーではなく、この「答え」を投稿するときに、私は自分自身を識別するための選択肢について、このページの一番下を長く見ていました。 OpenIDログインを使用するか、または私が持っていない場合はそれを取得するという選択肢は、Twitterやfacebookについては何もしていませんが、OAuthはその仕事には不十分であることを示唆しているようです。しかし、それから私は別のウィンドウを開いてstackoverflowの一般的なサインアッププロセスを探しました - そして、FacebookやTwitterを含むたくさんのサードパーティの認証オプションがあるのを見てください。最終的に私は自分の友達リストへのstackoverflowアクセスを許可したくないという理由で自分のグーグルID（これはOpenIDです）を使用することにしました。私が考えていた用途にはOAuthが適しているという証拠.
誰かがこの種の複数の第三者認証設定をサポートすることについての情報や情報へのポインタ、あるいは認証を取り消したり第三者のサイトへのアクセスを失ったりするユーザへの対処方法についての情報を投稿できれば本当に素晴らしいでしょう。また、私のユーザー名は、私がそれを設定したい場合に基本認証でアクセスできる一意のstackoverflowアカウントを識別し、他のサードパーティのオーセンティケーターを通してこの同じアカウントにアクセスするという印象も与えます。 Google、Facebook、Twitterのいずれかにログインした場合は、stackoverflowにログインします。このサイトがそれをやっているので、ここの誰かはおそらく主題に関するあるかなり良い洞察を持っています。 :-)
申し訳ありませんが、これは非常に時間がかかり、回答というよりは質問でした。しかしカールの発言は、OAuthとOpenIDに関する大量のスレッドの中で投稿するのに最も適した場所のように思えました。私が見つけられなかったこれのためのよりよい場所があるならば、私は前もって謝罪します、私は試みました。
- OpenID は、OpenID Foundationによって管理されるオープン標準および分散認証プロトコルです。
- OAuth はアクセス委任のためのオープンスタンダードです。
- OpenID Connect （OIDC）OpenIDとOAuthの機能を結合します。つまり、認証と承認の両方を行います。
OpenID いくつかの "OpenIDプロバイダ"、すなわちアイデンティティプロバイダ（idP）によって管理される一意の _ uri _ の形式を取ります。
OAuth はXACMLと組み合わせて使用できます。OAuthは所有権の同意とアクセスの委任に使用され、XACMLは承認ポリシーの定義に使用されます。
_ oidc _ は単純なJSON Webトークン（JWT）を使用します。これは、 OAuth 2.0 の仕様に準拠したフローを使用して取得できます。 OAuth は _ oidc _ に直接関連しています。これは、 _ oidc _ が OAuth 2.0 の上に構築された認証レイヤだからです。
たとえば 、Googleアカウントを使用してAuth0にサインインすることを選択した場合は、 _ oidc _ を使用します。 Googleの認証に成功し、Auth0があなたの情報にアクセスすることを承認すると、GoogleはAuth0にユーザーと認証に関する情報を返信します。この情報はJSON Web Token（JWT）に返されます。アクセストークンと、必要に応じてIDトークンを受け取ります。 トークンの種類 ： 出典：OpenID Connect
アナロジー ：
組織は識別の目的で IDカード を使用し、それはチップを含み、それは 許可 すなわちキャンパス/ゲート/ ODCアクセスと共に従業員についての詳細を格納する。 IDカード は _ oidc _ のように振る舞い、 Chip は OAuth のように振る舞う。 より多くの例 そしてform wiki
OpenID あなたが誰であるかを証明します。
OAuth は、認証当事者が提供する機能へのアクセスを許可します。
私は現在OAuth 2.0とOpenIDの接続仕様に取り組んでいます。それで、ここに私の理解があります。
- OpenIDはGoogleの独自実装であり、新聞のWebサイトのようにGoogleでログインして記事にコメントを付けたり、その他のユースケースにコメントを付けることができます。だから本質的に、新聞のウェブサイトへのパスワード共有はありません。ここで定義を述べよう。エンタープライズアプローチにおけるこのアプローチはフェデレーションと呼ばれる。フェデレーションでは、認証と承認を行うサーバー（IDP、IDプロバイダーと呼ばれます）、および一般的にユーザー資格情報の管理者がいます。あなたがビジネスをしているクライアントアプリケーションはSPまたはサービスプロバイダと呼ばれます。同じ新聞ウェブサイトの例に戻ると、新聞ウェブサイトはSPここにあり、GoogleはIDPです。企業では、この問題はSAMLを使用して以前に解決されました。その当時、XMLはソフトウェア業界を支配していました。 Webサービスから設定まで、すべてXMLになっていたため、完全なフェデレーションプロトコルであるSAMLがあります。
OAuth：OAuthは、これらすべての種類の独自のアプローチを検討する標準として出現したので、OAuth 1.oを標準として使用しましたが、承認についてのみ説明しました。あまり気づいていない人がいましたが、それは拾い始めました。その後、2012年にOAuth 2.0がリリースされました。CTOであるArchitectsは、世界がクラウドコンピューティングに移行しつつあり、コンピューティングデバイスがモバイルやその他のそのようなデバイスに移行しているので、本当に注目を集め始めました。 OAuthは、ソフトウェアの顧客が1つの会社にIDPサービスを提供したり、Salesforce、SAPなどのさまざまなベンダーからの多数のサービスを提供したりする大きな問題を解決すると見なされています。それではOAuth 2.oを探りましょう。ああ、この間、GoogleはOAuthが実際には認証に対応していないことを感じ、IDPはどのようにユーザーデータをSP（実際にはSAMLで素晴らしく対処されています）に渡しました。好きです：
a。 OAuth 2.oは、クライアント登録がどのように行われるのか明確には述べていません。 SP（リソースサーバー）とクライアントアプリケーション（データを提供するAnalyticsサーバーがリソースサーバーで、そのデータを表示するアプリケーションがクライアント）との間の相互作用については何も言及されていません。
ここに技術的に与えられた素晴らしい答えがすでにあります、私は簡単な進化の観点を与えることを与えることを考えました
OAuth 2.0はセキュリティプロトコルです。それは認証NOR許可プロトコルではありません。
定義による認証は2つの質問に答えます。
- ユーザーは誰ですか？
- ユーザーは現在システム上にいますか？
OAuth 2.0には、以下の付与タイプがあります。
- client_credentials：あるアプリが別のアプリと対話し、複数のユーザーのデータを変更する必要があるとき。
- authorization_code：ユーザーは、クライアントが保護されたリソースへのアクセスに使用できるaccess_tokenを発行するように承認サーバーを委任します。
- refresh_token：access_tokenが期限切れになると、更新トークンを利用して新しいaccess_tokenを取得できます。
- password：ユーザーは、認証サーバーを呼び出してaccess_tokenを受け取るクライアントに自分のログイン資格情報を提供します。
4つすべてに共通点が1つあります。access_tokenは、保護されたリソースにアクセスするために使用できる成果物です。
Access_tokenは、「認証」プロトコルが答えなければならない2つの質問に対する答えを提供しません。
例 Oauth 2.0を説明する（クレジット：OAuth 2 in Action、Manningの出版物）
チョコレートについて話しましょう。ファッジ、アイスクリーム、ケーキなど、チョコレートでたくさんの菓子を作ることができます。しかし、これらのどれもチョコレートと見なすことはできません。たとえチョコレートが主成分であるように聞こえても、菓子を作るためにクリームやパンなどの他の複数の成分が必要だからです。同様に、OAuth 2.0はチョコレートで、Cookie、TLSインフラストラクチャ、Identity Providerは「認証」機能を提供するために必要なその他の要素です。
認証が必要な場合は、access_tokenとは別に「id_token」を提供するOpenID Connectを使用して、すべての認証プロトコルが答えなければならない質問に答えます。
このコメントにあるように、この質問の特定の側面に対処したいと思います。
OAuth：何らかの機能へのアクセスを許可する前に、認証を行う必要がありますか？ so OAuth = OpenIdは何をし、いくつかの機能へのアクセスを許可しますか？ –ハッサンマカロフ6月21日1:57
はいといいえ。答えは微妙ですので、ご容赦ください。
OAuthフローがターゲットサービス（つまりOAuthプロバイダー）にリダイレクトする場合、isおそらくそれで認証する必要がありますトークンがクライアントアプリケーション/サービスに返される前のサービス。結果のトークンにより、クライアントアプリは特定のユーザーに代わってリクエストを行うことができます。
最後の文の一般性に注意してください。具体的には、「特定のユーザーに代わって」、not "- yo "。 「特定のユーザーが所有するリソースと対話する機能を持っている」とは、「あなたとターゲットリソースの所有者は同じ人である」ことを意味すると想定するのはよくあるエラーです。
この間違いをしないでください。
OAuthプロバイダーで認証するのは事実ですが（たとえば、ユーザー名とパスワード、またはSSLクライアント証明書、またはその他の方法で）、クライアントは何を返す必要がありますnot必ず身元の証明として受け取られます。例としては、別のユーザーのリソースへのアクセスが委任である（そしてプロキシによってOAuthクライアント）というフローがあります。承認は認証を意味するものではありません。
認証を処理するには、OAuth 2.0によって設定された基盤の上にある本質的に別のレイヤーであるOpenID Connectを検討する必要があります。 OpenID Connectに関する最も顕著な点を（私の意見では）キャプチャした引用文を以下に示します（ https://oauth.net/articles/authentication/ から）：
OpenID Connectは、OAuth 2.0を使用してユーザー認証を実行する相互運用可能な方法を定義する、2014年初頭に公開されたオープンスタンダードです。本質的に、それはチョコレートファッジのために広く公開されたレシピであり、多くのさまざまな専門家によって試され、テストされています。潜在的なIDプロバイダーごとに異なるプロトコルを作成する代わりに、アプリケーションは、1つのプロトコルを、必要な数のプロバイダーと話すことができます。 OpenID Connectはオープンスタンダードであるため、制限や知的財産に関する懸念なしに、誰でもOpenID Connectを実装できます。
OpenID ConnectはOAuth 2.0上に直接構築され、ほとんどの場合、OAuthインフラストラクチャとともに（またはその上に）デプロイされます。 OpenID Connectはまた、JSON Object Signing And Encryption（JOSE）スイートの仕様を使用して、さまざまな場所で署名および暗号化された情報を持ち運びます。実際、JOSE機能を備えたOAuth 2.0デプロイメントは、完全に準拠したOpenID Connectシステムを定義するための長い道のりであり、2つの間のデルタは比較的小さくなっています。しかし、このデルタは大きな違いを生みます。OpenIDConnectは、いくつかの重要なコンポーネントをOAuthベースに追加することで、上記の落とし穴の多くを回避します：[...]
次に、ドキュメントは（とりわけ）トークンIDとUserInfoエンドポイントを記述します。前者は、一連のクレーム（あなたが誰であるか、トークンが発行されたときなど）、および公開された公開キーを介してトークンの信頼性を検証するための署名を提供しますwithoutアップストリームサービスに問い合わせる必要があります）、後者は例えばOpenID Connectが標準化する前に人々が使用していたOAuthへのアドホックな拡張とは対照的に、すべて標準化された方法でユーザーの名/姓、メール、および同様の情報を要求します。
どちらのプロトコルも異なる理由で作成されました。 OAuthは第三者にリソースへのアクセスを許可するために作成されました。 OpenIDは、分散ID検証を実行するために作成されました。この ウェブサイト は次のように述べています：
OAuthは、エンドユーザーの身元を確認し、第三者に許可を与えるために設計されたプロトコルです。この検証によりトークンが生成されます。第三者はこのトークンを使用してユーザーに代わってリソースにアクセスできます。トークンにはスコープがあります。スコープは、リソースがユーザーからアクセス可能かどうかを確認するために使用されます。
OpenIDは、分散認証に使用されるプロトコルです。認証はアイデンティティに関するものです。ユーザーを確立することは、実際には彼がそうであると主張する人です。これを分散化するということは、このサービスは保護する必要があるリソースやアプリケーションの存在を認識していないことを意味します。それがOAuthとOpenIDの大きな違いです。
OpenIdは認証を処理するためにOAuthを使用します。
同様に、.NETはWindows APIに依存しているようです。あなたは直接Windows APIを呼ぶことができます、しかしそれはとても広くて、複雑でそしてメソッド引数はとても広大です、あなたは簡単に間違い/バグ/セキュリティ問題を犯すことができます。
OpenId/OAuthと同じです。 OpenIdは、認証の管理はOAuthに依存していますが、特定のトークン（Id_token）、デジタル署名、および特定のフローを定義しています。