ToppyMicroServices

RFC 9700 クイズ

現在のOAuth threat mitigationとdeployment判断

🇺🇸🇯🇵
0 / 0

参照仕様

Q1: authorization serverはregistered redirect URIとrequest valueをどう比較すべき?

単一選択
**解説:** A: exact matchingでattacker-controlledなURI variationへのauthorization response送信を防ぐ. B: domain-level matchingは広すぎattacker-controlled hostやpathを含みうる. C: decode後のprefix matchでは、exactに登録されていないrequest URIまで受理しうる。

Q2: authorization code flowでPKCEが重要な理由はどれ?

単一選択
**解説:** A: PKCEはcode redemptionをverifierへbindするものでstorage encryptionではない. B: interceptされたcodeは対応するcode verifierなしではredeemできない. C: PKCEはexact redirect matchingや、適用される場合のclient authenticationを置き換えない。

Q3: Resource Owner Password Credentials grantに対するRFC 9700の立場はどれ?

単一選択
**解説:** A: browser constraintでcredential exposureやphishing riskは消えない. B: refresh-token lifetimeはresource owner passwordの収集を解決しない. C: RFC 9700はcredential exposureとstronger authenticationとの非互換性からこのgrantを禁止する.

Q4: clientが一般にimplicit grant responseを避けるべき理由はどれ?

単一選択
**解説:** A: authorization code flowならstronger bindingとtoken-endpoint protectionを使える. B: response typeだけでtokenがsender-constrainedになるわけではない. C: exact redirect URI checkは両flowで重要である.

Q5: clientがmultiple authorization serverをsupportする. mix-up attackを防ぐcontrolはどれ?

単一選択
**解説:** A: lateかつuntrustedなchoiceはendpointとissuerの関係をattackerに混同させる. B: これらのmechanismでwrong authorization serverからのresponseをdetectできる. C: correlation valueのreuseはresponse-to-request bindingを弱める.

Q6: public clientがrefresh tokenを受け取る. authorization serverはどのreplay defenseを使うべき?

単一選択
**解説:** A: client identifierはsecretではなくrefresh-token replayをdetectしない. B: longいvalidityはtoken theftのharmを増やす. C: これらのmechanismでstolen refresh tokenのreplayをpreventまたはdetectする.

Q7: access tokenをsender-constrainする目的はどれ?

単一選択
**解説:** A: 追加proofによりcopied tokenだけでは不十分になる. B: sender constrainingはTLS confidentialityとserver authenticationをreplaceしない. C: key-bound tokenでもaudience checkを省くとwrong resourceへ提示されうる.

Q8: clientとauthorization serverがopen redirectorを避けるべき理由はどれ?

単一選択
**解説:** A: open redirectはdestination controlの問題でTLS capability limitationではない. B: open redirectはtrusted URIをredirect trampolineへ変えうる. C: client typeとredirect endpointがopenかは独立している.

Q9: authorization-server mix-upの境界を直接閉じる変更はどれ？

単一選択

clientは一つのredirect URIで二つのauthorization serverをsupportする。stateは検証するが、redirect上のuntrustedなas query parameterからtoken endpointを選ぶ。authorization responseのissuer identifierは検証せず、serverごとのredirect URIも使わない。

**解説:** RFC 9700 Section 4.4.2は、authorization responseのissuer identification、またはauthorization serverごとに異なるredirect URIをmix-up countermeasureとする。Cはresponseをflow開始時のserverへbindする。endpoint選択がattacker-controlled input由来なら、stateだけではserverを認証できない。Aは検出が遅すぎ、Bはissuer bindingを変えず、Dはserver authenticationを失わせる。

Q10: TLSの保証を過大評価せず、replay経路を塞ぐcontrol setはどれ？

単一選択

agentがpayment API向けaudienceに限定されたbearer access tokenを受け取る。tokenはTLS-terminating gatewayを通り、gatewayはAuthorization field全体をcentral logへ書く。全hopはTLSだが、log readerは期限内にtokenをcopyして同じpayment APIを呼べる。

**解説:** RFC 9700 Sections 2.2.1と4.10.1は、盗まれたtokenのmisuseを減らすため、mutual TLSやDPoPでbindしたsender-constrained access tokenを推奨する。audience restrictionも有用だが、そのaudienceではcopyされたbearer tokenを使える。hop-by-hop TLSが保護するのはtransit中であり、gatewayがlogへ書いた後ではない。Cは不要なdisclosureを除き、脅威とecosystemが必要とする場合にはtokenだけの所持を不十分にする。A、B、Dはreplay経路を残す。