OAuth 1.0 では、2-legged は非常に簡単です。通常どおりリクエストを送信し、access_tokenヘッダーを省略するだけです。
OAuth 2.0 では状況が変わったようです (今日わかったように、劇的に :))。OAuth 2.0 では、リクエストにノンス、コンシューマ キー、タイムスタンプなどのヘッダーがなくなりました。これは次のように置き換えられます。
Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh
OAuth 2.0 で 3 レグ認証がどのように機能し、アプリケーション フローがどのように機能するかを理解しています。しかし、2.0 で 2 脚はどのように機能するのでしょうか? 2-legged と 3-legged OAuth 2.0 の両方をサポートできる API を設計することは可能ですか?
私はこれに関する情報を探していましたが、1.0 の 2-legged に関する情報はたくさん見つかりましたが、2.0 の情報はほとんど見つかりませんでした。
多くの調査の結果、client_credentials助成金の種類がこのシナリオに適していることがわかりました。この用語をグーグルに打ち込むと、非常に役立つリソースがたくさん見つかります。
これは 3-legged OAuth 2.0 の通常のフローです (ユーザーにサインインしてもらいます)。
アプリに認証用の次のエンドポイントがあるとします。
/oauth/auth
/oauth/token
通常（認証コード付与の場合）、ユーザーを/oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah
次に、認証時に、ユーザーはにリダイレクトされますmysite.com/blah?code=somecode
somecode次に、トークンを取得して交換します/oauth/token?code=somecode&client_id=myid&client_secret=mysecret
その後、トークンを使用して呼び出しを行うことができます。
client_credentialsこれは、 2-legged OAuth 2.0 を実装するためのアプリケーション フローです。これは非常に単純です。
このアプローチでは、認証を実行する必要はありません。
/oauth/token次のフォーム データを使用して単純に POST します。
grant_type=client_credentials&scope=view_friends
スコープはオプションであることに注意してください。その後、エンドポイントは、使用するアクセス トークンを直接返します (更新トークンは提供されません)。更新トークンが提供されないため、トークンの有効期限が切れると、再認証して新しいトークンを要求する必要があります。
これは、次の警告につながります。
もう 1 つの解決策は、Google OAuth APIのような JWT (JSON Web トークン) を使用することです。これは非常に複雑なプロセスですが、JWT を生成するためのライブラリが多数存在します。次に、次のフォーム データを投稿します (もちろん、URL はエンコードされています)。
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt
/oauth/tokenこれは、トークンを取得するために投稿されます。
2-legged および 3-legged OAuth 2.0 をサポートする API を作成できるかどうかの質問については、はい、可能です。
その後、/authエンドポイントは、ユーザーがサービスに対して認証する必要がある場合にのみ使用されます。
/tokenエンドポイントでは、JWT または client_credentials を使用しているかどうかについて、GET パラメーターの値を確認するだけですgrant_type。urn:ietf:params:oauth:grant-type:jwt-bearerclient_credentials
ユーザーに与える client_id と client_secret を生成するときに、複数をサポートしてgrant_typesいる場合は、ID とシークレットが生成された付与タイプを格納するデータベース列があることを確認してください。ユーザーごとに複数の許可タイプが必要な場合は、許可タイプごとに異なる資格情報のセットを生成します。