背景：OAuth 1.0aおよび2.0のクライアントおよびサーバースタックを作成しました。
OAuth 1.0aと2.0はどちらも、サーバーがユーザーのIDを保証する2レッグ認証と、サーバーがユーザーのID のコンテンツプロバイダーによって保証される3 レッグ認証をサポートしています。Three-legged認証では、承認リクエストとアクセストークンが関係します。OAuth1にもそれらがあることに注意することが重要です。
複雑なもの：三脚認証
OAuth仕様の主なポイントは、コンテンツプロバイダー（Facebook、Twitterなど）がサーバー（たとえば、クライアントに代わってコンテンツプロバイダーと通信することを望むWebアプリ）に、クライアントが何らかのIDを持っていることを保証することです。 。Three-Legged認証が提供するのは、クライアントまたはサーバーがそのIDの詳細（ユーザー名やパスワードなど）を知る必要がなくてもそれを実行できる機能です。
OAuthの詳細に深く入り込まない（？）：
- クライアントはサーバーに承認要求を送信し、サーバーがクライアントがそのサービスの正当なクライアントであることを検証します。
- サーバーはクライアントをコンテンツプロバイダーにリダイレクトして、そのリソースへのアクセスを要求します。
- コンテンツプロバイダーはユーザーのIDを検証し、多くの場合、リソースへのアクセス許可を要求します。
- コンテンツプロバイダーは、クライアントをサーバーにリダイレクトし、成功または失敗を通知します。このリクエストには、成功時の認証コードが含まれています。
- サーバーは、コンテンツプロバイダーに帯域外要求を行い、認証コードをアクセストークンと交換します。
サーバーは、アクセストークンを渡すことにより、ユーザーに代わってコンテンツプロバイダーにリクエストを送信できます。
各交換（クライアント->サーバー、サーバー->コンテンツプロバイダー）には共有シークレットの検証が含まれますが、OAuth 1は暗号化されていない接続で実行できるため、各検証はシークレットをネットワーク経由で渡すことができません。
お気づきのとおり、これはHMACで行われます。クライアントは、サーバーと共有するシークレットを使用して、認証リクエストの引数に署名します。サーバーは引数を受け取り、クライアントのキーを使用して自身に署名し、それが正当なクライアントであるかどうかを確認できます（上記のステップ1）。
この署名では、クライアントとサーバーの両方が引数の順序に同意する必要があるため（これらはまったく同じ文字列に署名します）、OAuth 1に関する主な不満の1つは、サーバーとクライアントの両方でソートと同じように署名します。これは厄介なコードであり、それが正しいか401 Unauthorized、ほとんど助けを借りずに取得できます。これにより、クライアントを作成する際の障壁が高まります。
OAuth 2.0は、SSLを介して実行する認証リクエストを要求することで、引数の並べ替えや署名の必要性を完全に排除します。クライアントはその秘密をサーバーに渡し、サーバーはそれを直接検証します。
同じ要件がサーバー->コンテンツプロバイダー接続にも存在します。これはSSLであるため、OAuthサービスにアクセスするサーバーの作成に対する1つの障壁が取り除かれます。
これにより、上記のステップ1、2、および5の処理が非常に簡単になります。
したがって、この時点で、サーバーには永続的なアクセストークンがあり、これはユーザーと同等のユーザー名/パスワードです。アクセストークンをリクエストの一部として（クエリ引数、HTTPヘッダー、またはPOSTフォームデータとして）渡すことにより、ユーザーに代わってコンテンツプロバイダーにリクエストを送信できます。
コンテンツサービスがSSL経由でのみアクセスされる場合は、これで完了です。プレーンなHTTPを介して利用できる場合、その永続的なアクセストークンを何らかの方法で保護したいと考えています。接続をスニッフィングすると、誰でもユーザーのコンテンツに永久にアクセスできるようになります。
OAuth 2で解決される方法は、更新トークンを使用することです。更新トークンは永続的なパスワードと同等になり、SSL経由でのみ送信されます。サーバーがコンテンツサービスにアクセスする必要がある場合、サーバーは更新トークンを短期間のアクセストークンと交換します。このようにして、すべてのスニファ可能なHTTPアクセスは、期限切れになるトークンを使用して行われます。GoogleはOAuth 2 APIで5分の有効期限を使用しています。
したがって、更新トークンを除いて、OAuth 2はクライアント、サーバー、コンテンツプロバイダー間のすべての通信を簡素化します。また、更新トークンは、コンテンツが暗号化されていない状態でアクセスされているときにセキュリティを提供するためにのみ存在します。
Two-legged認証
ただし、サーバーが独自のコンテンツへのアクセスを制御するだけでよい場合もあります。Two-legged認証により、クライアントはサーバーでユーザーを直接認証できます。
OAuth 2は、広く使用されていたOAuth 1の一部の拡張機能を標準化します。私が最もよく知っているのはTwitterによってxAuthとして紹介されたものです。OAuth 2では、リソース所有者のパスワード認証情報として確認できます。
基本的に、ユーザーの資格情報（ユーザー名とパスワード）でクライアントを信頼できる場合、クライアントはそれらをコンテンツプロバイダーと直接交換してアクセストークンを取得できます。これにより、モバイルアプリでのOAuthがより便利になります。3脚認証では、コンテンツサーバーでの承認プロセスを処理するために、HTTPビューを埋め込む必要があります。
OAuth 1では、これは公式の標準の一部ではなく、他のすべての要求と同じ署名手順が必要でした。
リソースオーナーパスワード認証情報を使用してOAuth 2のサーバー側を実装しました。クライアントの観点から見ると、アクセストークンの取得は簡単になりました。サーバーからアクセストークンをリクエストし、クライアントID /シークレットをHTTP Authorizationヘッダーとフォームデータとしてのユーザーのログイン/パスワード。
利点：シンプルさ
したがって、実装者の観点から見ると、OAuth 2に見られる主な利点は、複雑さが軽減されていることです。要求の署名手順は必要ありません。これは厳密には難しいことではありませんが、確かに手間がかかります。これにより、サービスのクライアントとして機能するために必要な作業が大幅に削減されます。これは、（現代のモバイルの世界では）痛みを最小限に抑えたい場所です。サーバー->コンテンツプロバイダー側の複雑さが緩和されることで、データセンターでのスケーラビリティが向上します。
そして、現在広く使用されているOAuth 1.0a（xAuthなど）のいくつかの拡張を標準化します。