ToppyMicroServices

RFC 6749 Quiz

OAuthのrole,grant,tokenを分ける

🇺🇸🇯🇵
0 / 0

References (URLs)

範囲: RFC 6749はOAuth 2.0のrole, grant, endpoint, token abstractionを定義します. RFC 9700は一部の歴史的選択を更新する現行deployment security guidanceです. valid access tokenだけでruntime, task, delegation, user identityに関する全claimを証明するものではありません.

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: authorization serverは埋め込みsecretを信頼してよいか

Multiple Choice

user browser内だけで動くJavaScript applicationに固定client secretがdownload codeとして埋め込まれています. serverはその値をregistered client由来のrequestだというproofに使おうとしています.

**Explanation:** A: obfuscationやminificationはcredential confidentialityを保ちません. B: RFC 6749 Section 2.1はcodeとcredentialへaccessできるbrowser-based applicationをpublic clientに分類します. Section 2.3はpublic-client authenticationをclient識別に依存しないことをMUST NOTとします. C: client credentialとresource-owner credentialは別です.

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

Multi-Select

clientはbrowser経由のauthorization code flowを使います. 現在は任意のHTTPS callback URIを許し, initiating transactionとのbindingも, code redemptionとinitiating client instanceのbindingもありません.

**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 Sections 3.1.2.3と10.12はredirect照合とCSRF対策を扱い,RFC 9700 Sections 2.1と2.1.1が現行のexact matching・PKCE guidanceを示します.

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 9700 Sections 2.1.1,2.1.2,2.4です.

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: RFC 6749 Sections 1.4と7では,token format,token attribute,resource serverへの提示方法はcompanion specificationまたはprofileに委ねられます.RFC 6749自体が全tokenにissuer・audience fieldを要求するわけではありません.A2A profileが適用するvalidation rule,追加evidence,acceptance policyを定め,mTLSやDPoPなどでtokenをsender-constrainできます. C: TLSはchannelを保護しますが,resource authorizationやscope enforcementを置き換えません.