問題タブ [refresh-token]

ドラフトOAuth2.0プロトコルのセクション4.2は、承認サーバーがaccess_token（リソースで自分自身を認証するために使用される）と、refresh_token純粋に新しいものを作成するために使用される、の両方を返すことができることを示していaccess_tokenます。

https://www.rfc-editor.org/rfc/rfc6749#section-4.2

なぜ両方を持っているのですか？を持っていないaccess_token限り、最後を作ってみませんか？refresh_tokenrefresh_token

告白しなければならないのは、私はこの疑問を非常に長い間持っていたのですが、まったく理解できませんでした。

認証トークンは金庫の鍵のようなもので、有効期限が切れると使用できなくなります。これで、別の使用可能なキーを取得するために使用できるマジック リフレッシュ トークンが与えられました。では、認証トークンの有効期限を更新トークンと同じに設定しないのはなぜですか? なぜわざわざ？

その正当な理由は何ですか、おそらく歴史的なものですか？本当に知りたい。ありがとう

YouTube Live Streaming API と統合するプログラムがあります。タイマーで実行されるため、更新トークンを使用して 50 分ごとに新しいアクセス トークンを取得するようにプログラムするのは比較的簡単でした。私の質問は、なぜですか？

YouTube で認証すると、更新トークンが付与されました。次に、この更新トークンを使用して、約 1 時間に 1 回、新しいアクセス トークンを取得します。リフレッシュ トークンを持っていれば、有効期限がないため、常にこれを使用して新しいアクセス トークンを取得できます。したがって、最初からアクセス トークンを提供し、リフレッシュ トークン システム全体を気にするよりも、これがどのように安全であるかはわかりません。

オンラインで見つけたいくつかの例に基づいて、Asp.net Core REST サービス用の JWT ミドルウェアをいくつか作成しました。応答は次のようになります。

access_token の作成方法を理解しました:

問題は、refresh_token をどのように作成するかです。高低を検索しましたが、それに関する多くのドキュメントが見つかりません。基本的に、すべてのリファレンスは、「新しい access_token を作成できる、より長い TTL を持つデータベースに保存されたトークン」と言っています。

では、refresh_token は access_token とまったく同じもので、TTL が長く、データベースに対して検証される追加の手順があるだけですか?

私が見た JWT 応答の例のいくつかは、refresh_token がはるかに短いように見えます。私の access_token は RSA515 を使用した証明書で署名されているため、文字列はちょっと長いです...

Box API での認証に JWT を使用しています。これは、ユーザーが (OAuth2 の場合のように) 資格情報を使用して明示的にログインする必要がないようにするためです。

私の問題は、ユーザー アクセス トークンが 60 秒間しか有効でないことです。

つまり、Box API にリクエストを行うたびに (たとえば、特定のファイルを見つけるためにいくつかのフォルダーを反復処理する)、新しいユーザー アクセス トークンをリクエストして、それがまだ有効であることを確認する必要があるということですか?

私の理解では、JWT にはリフレッシュ トークンがないため、これが唯一の解決策のようです。

60 秒は非常に短い時間です。各リクエストの時間を追跡する必要はありません。そのため、他の唯一のオプションは、API リクエストごとにトークンを再作成する必要があるようです。これはばかげているようです。

Go with OAuth を Google に対して構成しました。次に、アクセス トークンを使用して、gmail API、連絡先 API、ドライブ API などに対するリクエストを行います。これらには、 object ではなく、実際のアクセス トークンである文字列が必要です*oauth2.Token。

アクセス トークンが有効な間は、すべてが機能します。無効になると、データにアクセスできなくなります。サービスに対してクエリを実行する前に、更新トークンを使用して新しいアクセス トークンを取得する必要があるため、これは理にかなっています。

私の理解では*http.Client、OAuth トークンから作成すると、必要に応じて新しいアクセス トークンが自動的に更新されます。

GETただし、クライアントから最新のアクセス トークンを取得し、 Google API に対するリクエストの一部として使用してサービスを認証する方法については、よくわかりません。

要約すると：

クライアントがトークンの更新を処理する場合は、クライアントを使用してアクセス トークンを取得し、有効にする必要があります。どうやってそれをしますか？私は使用を検討しましたconfig.TokenSource(ctx, tok)が、その上で TokenSource を呼び出すことができますが、それはクライアントを必要としないため、私が知る限り、トークンは更新されません。

次のGitHubの問題で@hassoxから提供されたアドバイスを実装しようとしています:

https://github.com/ueberauth/guardian/issues/142

ユーザーがログインした後、トークンを生成し、ttl を持つ Cookie に保存します。

さらに、パイプラインに Plug ( の下に配置するGuardian.Plug.LoadResource) があります。:browser_auth

現時点でのプラグの外観は次のとおりです。

新しいトークンを作成し、それをセッションに保存して、サインイン ページに再ルーティングされるのではなく、目的のページに進むにはどうすればよいですか?

iOS で ADAL を使用してマルチ リソース サポートを有効にするにはどうすればよいですか。非常に多くのサイトで検索しましたが、Refresh Token と Access Token を使用して、複数のリソースを使用するフローを理解するのが難しいことがわかりました。誰かこのフローを簡単に説明してもらえますか?

ライブラリによると、ADTokenCacheStoreItem の accessToken は nil になります。これは、アイテムにマルチリソース リフレッシュ トークンが格納されている場合です。しかし、acquireTokenWithResource:clientId:redirectUri を呼び出すたびに、アクセス トークンとリフレッシュ トークンの両方を取得しています。その私のものはマルチソースリクエストです.私がする必要がある設定はありますか?

/*! 受け取ったアクセス トークン。アイテムがマルチリソース リフレッシュ トークンを格納する場合は、nil にする必要があります。/ @property NSStringアクセストークン;

また、エンドポイントの有無にかかわらず各 API を呼び出す前に、毎回 acquireTokenWithResource:clientId:redirectUri を呼び出す必要がありますか?それとも、各リソースのアクセス トークンと有効期限をキャッシュ/保存するのは私の責任ですか? また、マルチリソースの場合にサイレントログインを処理するにはどうすればよいですか?

ほぼすべてのフォーラムで、特に oauth2 と jwt を使用した Web アプリケーションのセキュリティ (モバイル アプリを考慮していない) について多くの議論が行われています。誰もがコメント/回答をこれとあれ、何とか..何とか..何とかセキュリティトークンについて入れました（「2016」の終わりまでに、貴重なWebのほとんどすべてがステートレスになった可能性があると仮定します）。真剣に、それがそれほど簡単かどうかはわかりませんが、攻撃者がユーザーのクライアント側の web アプリ access_token と refresh_token を盗むのはとてもリラックスして簡単であるかのように、誰もが架空の攻撃者に対して回答を書いていることがわかりました。攻撃者がクライアント側で access_token と refresh_token を発行した Web アプリを実際に侵害する可能性のあるさまざまな方法は何ですか? この種の侵害は、Web アプリを使用するユーザーにも依存しますか? 攻撃者は、クライアントと認可サーバー間の通信をどのくらい簡単に盗聴できるでしょうか? 誰かがショーケースしたい場合、オープンなコード例は高く評価されます。Web アプリのセキュリティについての面倒な議論ではなく、的を射た回答を求めます。たまたまQuoraのような質問だったらすみません。