2

私はRESTAPIを開発しています。現在、私はそれを最小限の安全性にしようとしています。私がこの主題について見つけた投稿のほとんどがかなり古いので、私はこの質問をしています。

認証のために、私はこのスキームを見つけました:

  • 基本認証
  • AWS認証プロトコル
  • OpenID
  • OpenIDコネクト
  • OAuth疑似認証

基本認証とAWS認証は、署名されたリクエストを送信し続けるため、最初の認証後に認証されたリクエストを維持します。

OpenIDとOAuth認証が(2番目の)リクエストを自動化して維持する方法がわかりませんか?リクエストごとにOAuth/OpenIDサーバーでアクセストークンを確認する必要がありますか?これにより、変更されたリクエストを受信しないようにREST APIをどのように保護しますか?

あなたが推奨する他のスキーム、アドバイス、または主題に関する資料を読むことはいつでも歓迎です。

4

1 に答える 1

1

ここでOAuthについて話します

i)Webアプリを作成し、GoogleのOAuthAPIを使用したい。
ii)ここでアプリを登録し、資格情報を取得します。
iii)これで、アプリでGoogleのSDKを使用してログインページを開き、資格情報を入力すると、Googleがそれを確認し、アクセストークンと更新トークンを送信します。
iv)アクセストークンを使用してGoogleのAPIにREST呼び出しを行い、ユーザーのデータを取得します。


さて、あなたが尋ねた質問に来てください-access token一般的に1時間生きます。はい、1時間以内にGoogleのAPIに対して行う必要のある認証済みの呼び出しは、同じアクセストークンを使用して行うことができます。
別のタイプのトークンがあります- Refresh Token。アプリはいつでもプロバイダーのトークン交換エンドポイントに到達し、更新トークンを-更新トークン+アクセストークンのペアに交換できます。

ここでも、1時間役立つアクセストークンと、いつでも交換できる更新トークンがあります。

更新トークンは、ユーザーがアプリへのアクセス許可を明示的に取り消すまで、必要な限り存続します。(Googleに、彼のリソースにアクセスしてほしくないことを伝えます!)

OAuthは、認証および承認されたクライアントのみがAPIにアクセスできるようにすることで、RESTAPIを安全にします。ただし、一般的に、OAuthは、サードパーティのクライアントがユーザーのリソースにアクセスする必要がある状況でのみ使用されます。

于 2013-04-24T09:32:55.700 に答える