OpenIDとOAuthの違いは何ですか？

OpenIDとOAuthの違いを本当に理解しようとしていますか？多分それらは2つの完全に別のものなのでしょうか？

OpenIDは認証（つまり、あなたが誰であるかを証明する）に関するものであり、OAuthは承認（つまり、元の認証を処理する必要なく機能/データなどへのアクセスを許可する）に関するものです。

OAuthを外部パートナーサイトで使用すると、ユーザーを再認証することなく、保護されたデータにアクセスできます。

ブログ記事「ユーザーの視点からのOAuth対OpenIDのは、」シンプルなユーザーの視点から、両者の比較とあり、「OAuthの-のOpenID：あなたは彼らは同じことだと思う場合している吠えるアップ間違ったツリーを」より多くの情報を持っていますそれについて。

OAuthとOpenIDを比較するには3つの方法があります。

1.目的

OpenIDはフェデレーテッド認証用に作成されています。つまり、サードパーティがユーザーの既存のアカウントを使用してユーザーを認証できるようにします。OpenIDの全体的なポイントは、任意のプロバイダーを使用できること（ホワイトリストを除く）であるため、連合という用語はここでは重要です。ユーザーが所有している他のアカウントを使用できるようにするために、プロバイダーと事前に取引を選択したり交渉したりする必要はありません。

OAuthは、ユーザーがサードパーティのアプリケーションとパスワードを共有する必要をなくすために作成されました。これは実際にはOpenIDの問題を解決する方法として始まりました。サイトでOpenIDをサポートしている場合、ユーザーがサイトにパスワードを持っていないため、HTTP基本認証情報（ユーザー名とパスワード）を使用してAPIを提供することはできません。

問題は、認証用のOpenIDと承認用のOAuthのこの分離にあり、両方のプロトコルが同じことの多くを実行できることです。これらはそれぞれ、異なる実装で必要な異なる機能のセットを提供しますが、基本的にはかなり互換性があります。コアでは、どちらのプロトコルもアサーション検証メソッドです（OpenIDは「これは誰であるか」というアサーションに制限されていますが、OAuthはAPIを介してサポートされるアサーションと交換できる「アクセストークン」を提供します）。

2.機能

どちらのプロトコルも、サイトがユーザーを別の場所にリダイレクトし、検証可能なアサーションを返す方法を提供します。OpenIDはIDアサーションを提供しますが、OAuthは、「OAuthプロバイダーに質問する」ために使用できるアクセストークンの形式でより一般的です。ただし、それぞれがサポートする機能は異なります。

OpenID - OpenIDの最も重要な機能は、その発見プロセスです。OpenIDでは、事前に使用する各プロバイダーをハードコーディングする必要はありません。ユーザーはディスカバリーを使用して、認証したいサード・パーティーのプロバイダーを選択できます。この検出機能は、ほとんどのWebユーザーが取得できない識別子としてHTTP URIを使用することで実装されているため、OpenIDのほとんどの問題も引き起こしています。OpenIDの他の機能は、DH交換を使用したアドホッククライアント登録のサポート、最適化されたエンドユーザーエクスペリエンスのための即時モード、およびプロバイダーへの別のラウンドトリップを行わずにアサーションを検証する方法です。

OAuth - OAuthの最も重要な機能は、追加のリクエストを行う長期的な方法を提供するアクセストークンです。OpenIDとは異なり、OAuthは認証で終わるのではなく、同じサードパーティサービスによって提供される追加のリソースにアクセスするためのアクセストークンを提供します。ただし、OAuthは検出をサポートしていないため、使用するプロバイダーを事前に選択してハードコーディングする必要があります。サイトにアクセスするユーザーは、あなたが事前に選択した識別子のみを使用できます。また、OAuthにはIDの概念がないため、ログインにそれを使用することは、カスタムパラメータを追加する（Twitterによって行われる）か、現在「ログインしている」ユーザーを取得するために別のAPI呼び出しを行うことを意味します。

3.技術的な実装

2つのプロトコルは、リダイレクトを使用してユーザー認証を取得する際に共通のアーキテクチャを共有します。OAuthでは、ユーザーは保護されたリソースとOpenIDでのIDへのアクセスを承認します。しかし、それは彼らが共有するすべてです。

各プロトコルには、要求または応答の信頼性を検証するために使用される署名の計算方法が異なり、登録要件もそれぞれ異なります。

OpenIDは（主に）識別/認証用であるため、stackoverflow.com私がchris.boyle.name（またはどこにでも）所有しているため、chris.boyle.name昨日所有していて評判ポイントを獲得したのと同じ人物であることがわかります。

OAuthは、ユーザーに代わってアクションを実行する許可のために設計されているためstackoverflow.com、Twitterのパスワードを知らなくても、（またはどこにいても）ユーザーに代わって自動的にツイートする許可を求めることができます。

多くの人がまだこれを訪れていますので、ここにそれを説明する非常に簡単な図があります

礼儀ウィキペディア

OAuth

委任に使用 authorizationのみます。つまり、パスワードを提供することなく、サードパーティのサービスに個人データの使用を許可することを意味します。また、OAuthの「セッション」は通常、ユーザーセッションよりも長く存続します。OAuthが認証を許可するように設計されていることを意味します

つまり、FlickrはOAuthを使用して、サードパーティのサービスが自分の代わりに人物の写真を投稿および編集できるようにします。フリッカーのユーザー名とパスワードを提供する必要はありません。

OpenID

authenticateシングルサインオンIDに使用されます。OpenIDがすべきことは、OpenIDプロバイダーがあなたが本人であることを証明できるようにすることだけです。ただし、多くのサイトはID認証を使用して承認を提供しています（ただし、2つは分離できます）。

すなわち、空港でパスポートを提示して、使用しているチケットに名前が記載されている人の名前を認証（または証明）します。

ユーザーがFacebookやTwitterでログインしたいだけの場合は、OAuthを使用します。ユーザーが自分のOpenIDプロバイダーを実行している首割りである場合は、「他のユーザーが自分のIDを所有することを望まない」ため、OpenIDを使用します。

• OpenIDはオープンスタンダードです、OpenID Foundationによって制御される分散認証プロトコルです。
• OAuthはオープンスタンダードですアクセス委任のです。
• OpenID Connect（OIDC）OpenIDとOAuthの機能を組み合わせて、認証と承認の両方を行います。

OpenIDは一意のURIの形式を取りますいくつかの「OpenIDプロバイダー」、つまりIDプロバイダー（idP）によって管理されるます。

OAuthはXACMLと組み合わせて使用​​できます。OAuthは所有権の同意とアクセスの委任に使用されますが、XACMLは承認ポリシーの定義に使用されます。

OIDCは、シンプルなJSON Web Token（JWT）を使用します。これは、OAuth 2.0仕様に準拠したフローを使用して取得できます。OIDCはOAuth 2.0の上に構築された認証レイヤーであるため、OAuthはOIDCに直接関連しています。

たとえば、Googleアカウントを使用してAuth0にサインインすることを選択した場合は、OIDCを使用しました。Googleでの認証に成功し、Auth0が情報にアクセスすることを承認すると、Googleはユーザーと実行された認証に関する情報をAuth0に送り返します。この情報は、JSON Web Token（JWT）で返されます。アクセストークンと、要求された場合はIDトークンを受け取ります。トークンのタイプ：ソース：OpenID Connect

類推：
組織はIDカードを識別目的で使用し、チップが含まれています。これには、承認（キャンパス/ゲート/ ODCアクセスなど）とともに従業員に関する詳細が格納されています。IDのようにカード行為OIDCやチップなどの行為のOAuth。その他の例とフォームWiki

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に「本当の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をお勧めし ます。

（ソース）

回答よりも質問の拡張ですが、上記の優れた技術的な回答にいくつかの視点を追加する場合があります。私は多くの分野で経験豊富なプログラマーですが、Webのプログラミングはまったくの初心者です。次に、Zend Frameworkを使用してWebベースのアプリケーションを構築しようとしています。

確かに、アプリケーション固有の基本的なユーザー名/パスワード認証インターフェースを実装しますが、ユーザー数の増加に対して、さらに別のユーザー名とパスワードを考えることが抑止力になることを認識してください。正確にはソーシャルネットワーキングではありませんが、アプリケーションの潜在的なユーザーのかなりの割合が既にFacebookまたはTwitterアカウントを持っていることを知っています。アプリケーションは、これらのサイトからユーザーのアカウントに関する情報に実際にアクセスすることを望まない、または必要としない。単に、ユーザーが望まない場合に、ユーザーが新しいアカウント資格情報を設定する必要がないという便利さを提供したいだけです。機能の観点から見ると、それはOpenIDのポスターの子のように思えます。しかし、facebookやtwitterはOpenIDプロバイダーそのものではないようですが、ユーザーのデータにアクセスするためにOAuth認証をサポートしています。

私が2つについて読んだすべての記事とそれらの違いについては、上記のKarl Andersonの観察を見た後でなければ、「OAuthを認証に使用できます。これは、何もしない承認と考えることができます」 OAuthが自分のやりたいことには十分であるという明確な確認がありました。

実際、当時はメンバーではなかったので、この「回答」を投稿しようとしたとき、このページの下部で自分を識別するためのオプションを長く見つめていました。OpenIDログインを使用するオプション、または持っていなかった場合にログインIDを取得するオプションは、TwitterやFacebookについては何もないので、OAuthはその仕事に適していなかったようです。しかし、私は別のウィンドウを開いて、stackoverflowの一般的なサインアッププロセスを探しました。しかも、facebookやtwitterを含むサードパーティの認証オプションがたくさんあります。最終的に私は友人のリストへのstackoverflowアクセスを許可したくなかったという理由と、ユーザーについて共有したい他の何かのために私のグーグルID（OpenID）を使用することに決めました-しかし、少なくともそれは

誰かがこの種の複数のサードパーティ認証設定のサポートに関する情報または情報へのポインタを投稿でき、認証を取り消したり、サードパーティのサイトへのアクセスを失ったユーザーにどのように対処できるかは、本当に素晴らしいことです。また、ここでのユーザー名は、設定したい場合に基本認証でアクセスできる一意のStackoverflowアカウントを識別し、他のサードパーティ認証システムを介してこの同じアカウントにアクセスするという印象も得ます（たとえば、ログに記録されたと見なされるため） google、facebook、twitterのいずれかにログインしている場合は、stackoverflowにログインします...）。このサイトがそれをやっているので、おそらくここの誰かがその主題についてかなり良い洞察を持っているでしょう。:-)

申し訳ありませんでしたが、回答が長くなりました。回答よりも質問の方が多かったのですが、Karlの発言により、OAuthとOpenIDのスレッドが大量にある中で投稿するのに最も適した場所のように思えました。見つけられなかったより良い場所がある場合は、事前に謝罪しました。

OpenIDはあなたが誰であるかを証明します。

OAuthは、承認者が提供する機能へのアクセスを許可します。

現在、OAuth 2.0とOpenID接続仕様に取り組んでいます。だからここに私の理解があります：それ以前は：

1. OpenIDはGoogleの独自の実装であり、新聞のウェブサイトのように、Googleを使用してログインしたり、記事にコメントしたりできる他のユースケースなどのサードパーティアプリケーションを許可しています。したがって、本質的には、新聞のウェブサイトへのパスワード共有はありません。ここで定義を付けましょう。このエンタープライズアプローチのアプローチはフェデレーションと呼ばれます。フェデレーションでは、認証と承認を行うサーバー（IDP、アイデンティティプロバイダーと呼ばれます）と、通常はユーザー資格情報の管理者がいます。あなたがビジネスを持っているクライアントアプリケーションはSPまたはサービスプロバイダーと呼ばれます。同じ新聞のウェブサイトの例に戻ると、新聞のウェブサイトはここでSP、GoogleはIDPです。企業では、この問題は以前にSAMLを使用して解決されていました。当時、XMLはソフトウェア業界を統治するために使用されていました。Webサービスから構成に至るまで、すべてがXMLに移行していたため、SAMLを使用しています。

2. OAuth：OAuthは、これらすべての種類の独自のアプローチを検討する標準として出現したため、OAuth 1.oを標準として使用しましたが、承認のみに対応しています。多くの人は気づきませんでしたが、それは一種の上昇を始めました。その後、2012年にOAuth 2.0が導入されました。CTO、アーキテクトは、世界がクラウドコンピューティングに移行し、コンピューティングデバイスがモバイルやその他のデバイスに移行するにつれて、注目を集め始めました。OAuthは、ソフトウェアの顧客が1つの会社にIDPサービスを提供し、salesforce、SAPなどのさまざまなベンダーからの多くのサービスを提供するという主要な問題を解決するものと見なされていました。したがって、ここでの統合はフェデレーションシナリオのように見えますが、SAMLの使用はコストがかかりますでは、OAuth 2.oを見てみましょう。ああ、この間、GoogleはOAuthが実際に

   a。OAuth 2.oは、クライアントの登録がどのように行われるかを明確に述べていません。SP（リソースサーバー）とクライアントアプリケーション間の相互作用については何も触れられていません（データを提供するアナリティクスサーバーがリソースサーバーであり、そのデータを表示するアプリケーションがクライアントであるなど）

ここに技術的に与えられた素晴らしい答えはすでにあります、私は簡単な進化の展望を与えることを考えました

OpenIdはOAuthを使用して認証を処理します。

類推すると、それは.NETがWindows APIに依存しているようなものです。Windows APIを直接呼び出すこともできますが、それは非常に広範で複雑であり、メソッドの引数は非常に大きいため、簡単にミス/バグ/セキュリティの問題を引き起こす可能性があります。

OpenId / OAuthと同じです。OpenIdはOAuthに依存して認証を管理しますが、特定のトークン（Id_token）、デジタル署名、および特定のフローを定義します。

このコメントで捉えたように、この質問の特定の側面に取り組みたいと思います。

OAuth：一部の機能へのアクセスを許可する前に、認証を行う必要がありますよね？したがって、OAuth = OpenIdが行うこと+一部の機能へのアクセスを許可しますか？–ハッサンマカロフ6月21日1:57

はいといいえ。答えは微妙なので、我慢してください。

OAuthのフローが対象のサービス（のOAuthプロバイダー、ある）にリダイレクトするとき、それはあります、トークンがクライアントアプリケーション/サービスに返される前に、そのサービスで認証する必要可能性があります。結果のトークンにより、クライアントアプリは特定のユーザーに代わってリクエストを行うことができます。

最後の文の一般性に注意してください。具体的には、「あなたに代わって」ではなく、「特定のユーザーに代わって」と書きました。「特定のユーザーが所有するリソースと対話する機能を持っている」とは、「あなたとターゲットリソースの所有者が同じである」ことを意味すると想定することは一般的なエラーです。

この間違いをしないでください。

OAuthプロバイダーを使用して認証することは事実です（たとえば、ユーザー名とパスワード、SSLクライアント証明書、またはその他の手段による）。クライアントが受け取るものは、必ずしもIDの証明と見なされるべきではありません。例としては、別のユーザーのリソースへのアクセスがあなたに委任されたフローがあります（プロキシによって、OAuthクライアント）。承認は認証を意味するものではありません。

認証を処理するには、OAuth 2.0によって設定された基盤の上にある本質的に別のレイヤーであるOpenID Connectを調べたいと思うでしょう。OpenID Connect（https://oauth.net/articles/authentication/から）に関する最も顕著なポイントを（私の意見では）キャプチャした引用は次のとおりです。

OpenID Connectは、OAuth 2.0を使用してユーザー認証を実行する相互運用可能な方法を定義する、2014年初頭に公開されたオープンスタンダードです。本質的に、それはチョコレートファッジの広く公開されているレシピであり、多種多様な専門家によって試され、テストされてきました。潜在的なアイデンティティプロバイダーごとに異なるプロトコルを構築する代わりに、アプリケーションは、使用したい数のプロバイダーに対して1つのプロトコルを使用できます。OpenID Connectはオープンスタンダードであるため、制限や知的財産の懸念なしに誰でも実装できます。

OpenID ConnectはOAuth 2.0上に直接構築されており、ほとんどの場合、OAuthインフラストラクチャと一緒に（またはその上に）デプロイされます。OpenID Connectは、JSONオブジェクト署名および暗号化（JOSE）仕様のスイートも使用して、署名および暗号化された情報をさまざまな場所に持ち運びます。実際、JOSE機能を備えたOAuth 2.0デプロイメントは、完全に準拠したOpenID Connectシステムを定義するための長い道のりであり、2つの間の差分は比較的小さいです。しかし、そのデルタは大きな違いを生み、OpenID ConnectはOAuthベースにいくつかの主要なコンポーネントを追加することにより、上で説明した多くの落とし穴を回避します：[...]

次に、ドキュメントは（とりわけ）トークンIDとUserInfoエンドポイントについて説明します。前者は一連のクレーム（あなたが誰であるか、トークンが発行されたときなど）を提供し、上流のサービスに問い合わせることなく、公開された公開鍵を介してトークンの信頼性を検証するための署名を提供します。後者は、たとえば、OpenID Connectが標準化する前に人々が使用していたOAuthのアドホック拡張とは対照的に、すべて標準化された方法でユーザーの姓名、電子メール、および同様の情報を要求する手段。

どちらのプロトコルもさまざまな理由で作成されました。OAuthは、第三者がリソースにアクセスすることを許可するために作成されました。OpenIDは、分散ID検証を実行するために作成されました。このウェブサイトは次のように述べています：

OAuthは、エンドユーザーのIDを確認し、サードパーティに権限を付与するように設計されたプロトコルです。この検証により、トークンが生成されます。サードパーティはこのトークンを使用して、ユーザーに代わってリソースにアクセスできます。トークンにはスコープがあります。スコープは、ユーザーがリソースにアクセスできるかどうかを確認するために使用されます

OpenIDは、分散認証に使用されるプロトコルです。認証はアイデンティティに関するものです。ユーザーを確立することは、実際には彼がそうであると主張する人です。それを分散化するということは、このサービスが保護する必要のあるリソースやアプリケーションの存在を認識していないことを意味します。これが、OAuthとOpenIDの主な違いです。

OpenID Connectは、OAuth 2.0承認プロトコルを拡張して認証プロトコルとして使用するため、OAuthを使用してシングルサインオンを実行できます。OpenID Connectは、IDトークンの概念を導入しています。これは、クライアントがユーザーのIDを確認できるようにするセキュリティトークンです。

OAuth 2.0はセキュリティプロトコルです。これは、認証でも承認プロトコルでもありません。

認証は、定義により2つの質問に答えます。

1. ユーザーは誰ですか？
2. ユーザーは現在システムに存在していますか？

OAuth 2.0には次の付与タイプがあります

• client_credentials：あるアプリが別のアプリとやり取りして、複数のユーザーのデータを変更する必要がある場合。
• authorization_code：ユーザーは許可サーバーを委任して、クライアントが保護されたリソースへのアクセスに使用できるaccess_tokenを発行します
• refresh_token：access_tokenの有効期限が切れると、更新トークンを利用して新しいaccess_tokenを取得できます
• パスワード：ユーザーは、認証サーバーを呼び出し、access_tokenを受信するクライアントにログイン資格情報を提供します

4つすべてに共通する点が1つあります。それは、保護されたリソースにアクセスするために使用できるアーティファクトです。

access_tokenは、「認証」プロトコルが回答する必要がある2つの質問に対する回答を提供しません。

例Oauth 2.0を説明（クレジット：OAuth 2 in Action、Manning出版物）

チョコレートについて話しましょう。ファッジ、アイスクリーム、ケーキなど、チョコレートから多くの菓子を作ることができます。しかし、チョコレートは主な成分のように聞こえますが、菓子を作るためにクリームやパンなどの他の複数の成分が必要であるため、これらのどれもチョコレートと同等とは言えません。同様に、OAuth 2.0はチョコレートであり、Cookie、TLSインフラストラクチャ、アイデンティティプロバイダーは、「認証」機能を提供するために必要なその他の要素です。

認証が必要な場合は、すべての認証プロトコルが回答する必要がある質問に回答する「id_token」を提供するOpenID Connectを利用できます。

OAuthは承認に加えて認証を構築します。ユーザーは自分のIDへのアクセスをアプリケーションに委任します。アプリケーションはID APIのコンシューマーになり、最初にクライアントを承認したユーザーを確認しますhttp://oauth.net/記事/認証/