記事では、OAuth 2.0を取得する4つの方法を紹介します

OAuth2.0は認証メカニズムであり、主にトークン（トークン）の発行に使用されることを理解する

記事ディレクトリ

1つ、RFC 6749

OAuth 2.0の標準はRFC 6749です。このドキュメントでは、最初にOAuthについて説明します。

OAuthは、2つの異なる役割（クライアントとリソース所有者）を分離する認証レイヤーを導入します。…リソースの所有者が同意すると、リソースサーバーはクライアントにトークンを発行できます。クライアントはトークンを介してデータを要求します。

この一節の意味は、OAuthのコアはサードパーティのアプリケーションにトークンを発行することです。次に、RFC 6749は次のように記述しました。

（インターネットには多くのシナリオがあるため）この標準で
は、トークンを取得するための4つの承認付与メソッドが定義されています。つまり、OAuth 2.0では、トークンを取得するための4つの手順が規定されています。自分に最も適したものを選択して、サードパーティのアプリケーションにトークンを発行できます。ここに4つの承認方法があります

許可コード（authorization-code）
非表示（暗黙）
パスワード（password）：
クライアント資格情報（クライアント資格情報）

どのような認証方法でも、サードパーティのアプリケーションがトークンを申請する前に、まずシステムに提出して申請し、独自のIDを説明してから、クライアントIDとクライアントシークレットの2つの識別コードを取得する必要があります。キー（クライアントシークレット）。これは、トークンが悪用されるのを防ぐためです。ファイルされていないサードパーティのアプリケーションは、トークンを取得しません。

2.最初の認証方法：認証コード

承認コード（承認コード）は、サードパーティのアプリケーションが最初に承認コードを申請し、次にそのコードを使用してトークンを取得することを意味します

この方法は最も一般的に使用されるプロセスであり、最高のセキュリティを備えており、バックエンドを使用するWebアプリケーションに適しています。認証コードはフロントエンドを介して送信され、トークンはバックエンドに格納され、リソースサーバーとのすべての通信はバックエンドで完了します。このフロントエンドとバックエンドの分離により、トークンの漏洩を回避できます。

最初のステップでは、A Webサイトがリンクを提供し、ユーザーがそれをクリックすると、B Webサイトにリダイレクトされ、ユーザーデータがA Webサイトで使用されることを承認します。以下は、A WebサイトからB Webサイトへの概略リンクです。

https://b.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

上記のURLでは、response_typeパラメーターは認証コード（code）を返す要求を示し、パラメーターはclient_idBに要求者をredirect_uri通知し、パラメーターはBが要求を受け入れまたは拒否した後のリダイレクトURLであり、scopeパラメーターは要求された許可範囲を示します（ここでは読み取り専用です）。

ここに画像の説明を挿入
2番目のステップでは、ユーザーがリダイレクトされた後、WebサイトBがユーザーにログインを要求し、WebサイトAを承認することに同意するかどうかを尋ねます。ユーザーが同意すると、B Webサイトはredirect_uriパラメーターで指定されたURLに戻ります。リダイレクトすると、以下に示すように、認証コードが返されます。

https://a.com/callback?code=AUTHORIZATION_CODE

上記のURLでは、codeパラメーターは認証コードです。

ここに画像の説明を挿入
3番目のステップでは、ウェブサイトAが認証コードを取得した後、バックエンドのウェブサイトBにトークンをリクエストできます。

https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL

上記のURLでは、client_idパラメーターとclient_secretパラメーターを使用して、BがAのIDを確認できるようにしclient_secretます（パラメーターは機密であるため、要求はバックエンドでのみ送信できます）。grant_typeパラメーターの値はであり、AUTHORIZATION_CODE使用される認証方法が認証コードであることを示し、codeパラメーターは前のステップで取得されますredirect_uri受信した認証コード。パラメーターは、トークンが発行された後のコールバックURLです。

ここに画像の説明を挿入
4番目のステップでは、WebサイトBが要求を受け取った後にトークンを発行します。具体的な方法は、redirect_uriで指定されたURLにJSONデータを送信することです。

{
    
        
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{
    
    ...}
}

上記のJSONデータでは、access_tokenフィールドはトークンであり、Aウェブサイトはそれをバックエンドで取得しました。
ここに画像の説明を挿入

3. 2番目の認証方法：非表示

一部のWebアプリケーションは、バックエンドのない純粋なフロントエンドアプリケーションです。現時点では、上記の方法は使用できません。トークンはフロントエンドに保存する必要があります。

RFC 6749は2番目の方法を指定しており、トークンを直接フロントエンドに発行できます。このメソッドには認証コードの中間ステップがないため、（認証コード）が「暗黙的」と呼ばれます。

最初のステップで、WebサイトAは、ユーザーがWebサイトBにジャンプし、ユーザーデータをWebサイトAで使用することを承認する必要があるリンクを提供します。

https://b.com/oauth/authorize?
  response_type=token&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

上記のURLでは、response_typeパラメーターはですtoken。つまり、トークンを直接返す必要があります。

2番目のステップでは、ユーザーはBのWebサイトにジャンプし、ログイン後にAのWebサイトに承認を与えることに同意します。このとき、ウェブサイトBはredirect_uriパラメータで指定されたリダイレクトURLにジャンプし、トークンをURLパラメータとしてウェブサイトAに渡します。

https://a.com/callback#token=ACCESS_TOKEN

上記のURLでは、tokenパラメーターはトークンなので、ウェブサイトAはフロントエンドで直接トークンを取得します。

トークンの場所は、クエリ文字列（querystring）ではなく、URLアンカー（フラグメント）であることに注意してください。これは、OAuth 2.0がリダイレクトURLをHTTPプロトコルにすることを許可しているため、「中間者攻撃」のリスクがあり、ブラウザーがリダイレクトするためです。アンカーポイントがサーバーに送信されない場合、トークン漏洩のリスクが軽減されます

この方法で直接トークンをフロントエンドに渡すのは非常に安全ではありません。したがって、これは、セキュリティ要件の低い一部のシナリオでのみ使用でき、トークンの有効期間は非常に短くなければなりません。通常、セッション（セッション）が有効で、ブラウザーがオフになっていると、トークンは無効になります。

4. 3番目の認証方法：パスワードタイプ

アプリケーションを非常に信頼している場合、RFC 6749を使用すると、ユーザーはアプリケーションにユーザー名とパスワードを直接伝えることもできます。アプリケーションはパスワードを使用してトークンを申請します。この方法は「パスワード」と呼ばれます。

最初のステップでは、WebサイトAはユーザーにWebサイトBのユーザー名とパスワードを提供するように要求します。取得後、AはBに直接トークンを要求します。

https://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

上記のURLでは、grant_typeパラメータは、ここでは、認証方式でpassword「パスワードタイプ」を意味し、usernameそしてpasswordBのユーザー名とパスワードです。

2番目のステップでは、B Webサイトが認証に合格した直後にトークンが付与されます。現時点ではリダイレクトする必要はありませんが、トークンをJSONデータにHTTP応答として挿入するため、Aはトークンを取得します。

この方法では、ユーザーが自分のユーザー名/パスワードを入力する必要があります。これは明らかに非常にリスクが高いため、他の認証方法を使用できない状況にのみ適しています。ユーザーが非常に信頼できるアプリケーションでなければなりません。

5. 4番目の認証方法：証明書の種類

最後の方法はクライアント資格情報です。これは、フロントエンドのないコマンドラインアプリケーション、つまりコマンドラインでのトークンの要求に適しています。

最初のステップでは、AアプリケーションがコマンドラインでBにリクエストを送信します。

https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

URLの上に、grant_typeパラメータがに等しいclient_credentials利用券を表し、client_idそしてclient_secretそのBにAの身元を確認します。

2番目のステップでは、トークンはWebサイトBの検証に合格した直後に返されます。

この方法で与えられるトークンは、サードパーティアプリケーション用であり、ユーザー用ではありません。つまり、複数のユーザーが同じトークンを共有する可能性があります。

（1）トークンの使用

ウェブサイトAがトークンを取得すると、ウェブサイトBのAPIからデータをリクエストできます。

この時点で、APIに送信されるすべてのリクエストはトークンを運ぶ必要があります。具体的な方法は、リクエストのヘッダーにAuthorizationフィールドを追加することで、トークンはこのフィールドに配置されます。

curl -H "Authorization: Bearer ACCESS_TOKEN" \
"https://api.b.com"

上記のコマンドでACCESS_TOKENは、取得したトークンです

（2）トークンの更新
。トークンの有効期限が切れていませんか？上記の手順を再度行って、新しいトークンを申請するようにユーザーに求められた場合、エクスペリエンスは良くないので不要です。OAuth 2.0では、ユーザーはトークンを自動的に更新できます。

特定の方法は、WebサイトBがトークンを発行するときに一度に2つのトークンを発行することです。1つはデータの取得に使用され、もう1つは新しいトークン（更新トークンフィールド）の取得に使用されます。トークンの有効期限が切れる前に、ユーザーは更新トークンを使用して、トークンの更新要求を送信します。

https://b.com/oauth/token?
  grant_type=refresh_token&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET&
  refresh_token=REFRESH_TOKEN

上記のURLでは、grant_typeパラメーターrefresh_tokenはトークンの更新が必要であることを示し、client_idパラメーターとclient_secretパラメーターはIDの確認に使用され、refresh_tokenパラメーターはトークンの更新に使用されるトークンです。

Bウェブサイトが確認された後、新しいトークンが発行されます。