OAuth 2.0とは何ですか?
OAuth 2.0 は、汎用アプリケーションがユーザーに代わってオンライン サービスにアクセスできるようにするために作成されたオープン スタンダードの現在のバージョンです。つまり、ユーザーの ID を使用して、それらのサービス用のユーザー名とパスワードをそれらのアプリケーションに提供することなく、オンライン サービスにアクセスできるようにします。
それはどういう意味ですか？具体的な例を挙げていただけますか？
OAuth 2.0 (略して OAuth) は、たとえば、ブログに何かを投稿し、それを Instagram、Twitter、またはその他のソーシャル ネットワークで自動的に発表できるようにするものですが、それらのアカウントのパスワードをブログのコンテンツ管理システムに渡すことはありません。
OAuth 2.0 は認証に関するものですか?
いいえ、全く違います。OAuthは認証プロトコルではなく、オンラインサービスへの限定的なアクセスを認可するための標準化されたシステムです。これは重要な違いです！OAuthは、Instagram、LinkedIn、その他の誰かに対してあなたが本当にあなたであることを証明する方法とは全く関係ありません。OAuthは、あなたが何らかの方法で本人確認を行った後に、第三者にいわゆる「安全な委任アクセス」を提供するだけです。
参照: Google Chrome: 知っておくべきセキュリティと UI のヒント (TechRepublic Premium)
OAuth は実際にはどのように機能するのでしょうか?
OAuth は、その機能を果たすために、リソースオーナー、リソースサーバー、クライアント、そして認可サーバーという 4 つのアクター（役割）を区別します。リソースオーナーとは、リソースサーバー上でサードパーティのクライアントに何らかの作業を代行してもらいたいユーザーです。ブログで Instagram に新しい投稿を投稿したい場合、Instagram がリソースサーバー、あなたが Instagram アカウントのリソースオーナー、そしてブログの CMS がクライアントとなります。OAuth の中核を成す認可サーバーは、リソースオーナーの ID を検証した後、クライアントに「アクセストークン」と呼ばれるトークンを発行する部分です。
アクセス トークンは何をするのですか?
アクセストークンこそが、パスワードの共有を不要にする真の鍵です。個人的には、「一時アクセスバッジ」のような分かりやすい名前の方がずっと明確で、説明の必要がないと考えていましたが、現状では2種類のトークンを使うしかありません。アクセストークンは、クライアントがリソースサーバーに提示することで、限られた時間（多くの場合、数時間）だけユーザーに代わって行動することが承認されていることを証明するための小さなファイルです。OAuthアクセストークンで最もよく使われる形式はJWT（JSON Web Token）で、これはデータの暗号化とデジタル署名をサポートしています。アクセストークンに加えて、OAuthサーバーはリフレッシュトークンも発行します。リフレッシュトークンは他のトークンよりもはるかに長く有効ですが、いつでも取り消すことができます。リフレッシュトークンの目的は、クライアントが使用していたアクセストークンの有効期限が切れたときに、新しい一時アクセストークンをリクエストできるようにすることです。
アクセス トークンを使用すると、OAuth クライアントは私の名前で何でも実行できますか?
必ずしもそうではありません。これが OAuth の優れた点です。各アクセス トークンには、明確に定義された独自のスコープがあります。これは、きめ細かな権限のセットで、それぞれが 1 種類のアクションのみに対して実行されます。たとえば、異なるスコープを使用すると、2 つの独立したクライアントを同時に Twitter アカウントに接続し、1 つにはツイートの送信のみを許可し、もう 1 つにはTwitter タイムラインの読み取りのみを許可することができます。スコープのおかげで、OAuth は、それぞれ異なる権限を持つ必要な数のサービスとアプリケーションを同時に処理できます。多くのサービスには、集中管理された OAuth ダッシュボードのようなものも含まれており、ユーザーはこれを使用して、自分が許可したクライアントの数を追跡し、各クライアントが持っている権限を確認し、自由に更新または取り消しを行うことができます。
参照： パスワード侵害：ポップカルチャーとパスワードが混ざらない理由（無料PDF）（TechRepublic）
OAuth クライアントはどのようにしてアクセス トークンまたはリフレッシュ トークンを取得するのでしょうか?
認可サーバーからトークンを取得するには、OAuth クライアントを認可サーバーに「導入」する必要があります。つまり、誰かがそのトークンを受け取りたいということを証明する何らかの手段を持って認可サーバーにアプローチする必要があります。
OAuth 2では、このような「許可」を発行する主な方法が3つ定義されています。ソーシャルネットワークなどのオンラインサービスで最も一般的に使用されているのは「認可コード」と呼ばれるもので、「クライアント資格情報」は（ここでは簡略化して説明していますが）マシンツーマシンのシナリオに最適化されています。マシンツーマシンのシナリオでは、ソフトウェアプログラムは人間のユーザーではなく、他のプログラムから認可を取得する必要があります。最後に、「デバイスコード」と呼ばれる許可があります。これは、スマート家電やゲーム機など、ブラウザやキーボードを持たないデバイス向けに設計されています。詳細は省きますが、これらのデバイスコードは、デバイスの所有者が通常のデスクトップブラウザまたはモバイルブラウザから手動で認証サーバーに渡すことで認可手続きを完了できる別のコードを生成します。
OAuth の仕組みは理解できたと思いますが、もう一度プロセス全体を説明していただけますか?
では、ブログがTwitterですべての新しい投稿を自動的にアナウンスする許可を求めるケースで、すべての要素がどのように連携するかを見てみましょう。これを実現するために、ブログCMSは（もちろんログイン後に！）許可するかどうかを確認します。許可すると、ブログはTwitterの認証サーバーに、一意の識別コードを含む認証付与を提示します。認証サーバーはブラウザのダイアログウィンドウを使用して、対応するスコープを作成するために必要な1つ以上のアクション（ツイートの送信、ツイートへの返信、タイムラインのダウンロードなど）を明示的に承認するように求めます。許可すると、認証サーバーは取得したすべての情報をアクセストークンとしてまとめ、ブログCMSに送信します。この時点で、CMSはそのトークンを使用してリソースサーバー（つまりTwitter）に直接アクセスし、許可された操作を実行できるようになります。このプロセス全体における最大の特徴に気づきましたか？
特には。それは何でしょうか？
前の段落で説明したすべての処理は、2つの独立したフローに集約できます。1つは初期認可の承認フロー、もう1つは実際のアクセストークンの発行と使用フローです。これらはそれぞれ独立した異なるサーバーで処理されます。この非常にスケーラブルなアーキテクチャと、OAuthスコープによって提供される権限の粒度こそが、OAuth 2.0の有用性と成功の秘訣です。
