RFC 6749 Quiz

OAuthのrole,grant,tokenを分ける

0 / 0

References (URLs)

Q1: RFC 6749が定義する四つのroleはどれか.複数選択

Multi-Select
**Explanation:** A: resource ownerはprotected resourceへのaccessを許可できるentityです. B: clientはresource ownerの代理として,そのauthorizationに基づきprotected resourceを要求します. C: authorization serverはauthorization取得後にaccess tokenを発行します. D: resource serverはprotected resourceをhostし,valid access tokenを受け付けます. E: OAuthはnetwork broker roleを必須にしていません.

Q2: clientがphoto API用のOAuth access tokenを受け取った.RFC 6749だけから言えることはどれか

Multiple Choice
**Explanation:** A: OAuth 2.0はauthorization frameworkであり,OpenID Connectなどがstandardized login identity semanticsを追加します. B: access tokenは特定scopeとdurationのauthorizationを表します. C: token abstractionはpasswordの直接共有を置き換え,clientにはopaqueな場合もあります.

Q3: authorization grantとaccess tokenの違いはどれか

Multiple Choice
**Explanation:** A: 両者は異なるprotocol boundaryで使います. B: 向きが逆で,abstract flowのresource serverはgrant issuerではありません. C: clientはgrantをauthorization serverへ提示し,得たaccess tokenをresource serverへ提示します.

Q4: authorization code flowの重要なsecurity propertyはどれか

Multiple Choice
**Explanation:** A: authorization serverがresource-owner authenticationを仲介し,clientにはcodeを返すため,owner credentialをclientへ渡しません. B: implicit flowのexposure riskです. C: codeはclient identifierとredirect URIにbindされ,short-livedかつsingle-useです.

Q5: user browser内だけで動くJavaScript applicationに,固定client secretがdownload codeとして埋め込まれている.このsecretをどう扱うべきか

Multiple Choice
**Explanation:** A: obfuscationやminificationはcredential confidentialityを保ちません. B: browser-based・native applicationは通常shared secretを保持できず,authorization serverはその固定値だけでpublic clientを識別してはなりません. C: client credentialとresource-owner credentialは別です.

Q6: authorization-code redirect flowを保護するcontrolはどれか.複数選択

Multi-Select
**Explanation:** A: registered redirect URIとのexact matchingは,attackerがcredential受信先を選ぶことを防ぎます. B: syntax上有効でもattacker URIならcodeを奪えます. C: callbackを開始元user-agent transactionへbindすると,forgedまたは取り違えたcallbackを検出できます. D: PKCEにより,開始元client instanceが持つverifierなしではcodeを交換できません.RFC 6749は`state`によるCSRF対策を説明し,RFC 9700は条件を満たすPKCEやOpenID Connect `nonce`も扱います.

Q7: access tokenについて正しい記述はどれか

Multiple Choice
**Explanation:** A: tokenはclientにopaqueな場合が多く,JWTに限定されません. B: RFC 6749は全tokenをsenderへ自動bindingしません.bearer usageはRFC 6750,sender constrainingは追加mechanismが必要です. C: RFC 6749はauthorization abstractionを定め,resource serverでの利用方法はcompanion specificationが定めます.

Q8: refresh tokenを送る先はどこか

Multiple Choice
**Explanation:** A: refresh tokenはaccess token取得用credentialで,authorization serverだけで使います. B: RFC 6749はresource serverへ決して送らないとします. C: redirectで公開するとcredential leakageになります.更新はtoken endpointで行います.

Q9: RFC 9700の現行OAuth 2.0 security guidanceに合うものはどれか.複数選択

Multi-Select
**Explanation:** A: password grantはresource-owner credentialをclientへ露出するため,RFC 9700が禁止しています. B: authorization responseでaccess tokenを返すと,leakageとreplay riskが生じます. C: RFC 9700は,規定されたinjection・leakage対策を満たさないimplicitの利用を避けるよう求めます. D: public code-flow clientではPKCEがmandatoryで,confidential clientにもrecommendedです.RFC 6749はframeworkの基礎ですが,記載されたhistorical grantすべてが現在のdeployment recommendationではありません.

Q10: Agent BがAgent AからOAuth access tokenを受け取り,高impact taskを実行するか判断する.適切な結論はどれか

Multiple Choice

tokenはBのresource API向けにvalidです.さらに,提示可能なruntime,承認されたtask,onward delegation可否も判断する必要があります.

**Explanation:** A: OAuth tokenのvalidityだけではtask semantics,runtime attestation,完全なdelegation chainを自動的に証明しません. B: OAuthはauthorization-token frameworkを提供し,A2A profileが追加claimとacceptance policyを定めます.mTLSやDPoPなどでtokenをsender-constrainできます. C: TLSはchannelを保護しますが,resource authorizationやscope enforcementを置き換えません.