Uploaded image for project: 'PUBLIC - OAuth2'
  1. PUBLIC - OAuth2
  2. OAUTH2-44 REQ031 Prevent Privilege escalation
  3. OAUTH2-101

REQ031.UC001 PREVENT TOCTOU when registering new scopes after access tokens have been granted (global scopes/aliases)


    • Type: Sub-Task
    • Status: Closed
    • Priority: Minor
    • Resolution: Completed
    • Affects Version/s: None
    • Fix Version/s: 1.0-portal_7.1.0
    • Component/s: None
    • Labels:


      Undesirable postconditions:

      • Over time, the API surface covered by the user authorization grant is expanded without further consent from the user


      The default scope merging strategy will include all scopes registered by modules into respective global READ/WRITE scopes that can be granted. The problem is that this can lead to TOCTOU if a user grants one of these general scopes ahead of new scopes being registered, most likely by new modules.


      This leads to a OAuth2 client having access to a broader API surface than what the Portal User consented to.




      Events flow:

      1. Portal User grants an OAuth2 Application a global scope, say READ
      2. A new banking related module is deployed and this introduces a new scope called “BANKACCOUNT_READ” which is required to access its banking API
      3. The OAuth2 Application is now able to also call the banking API without needing to ask the Portal User for consent


      Expected result:

      • The OAuth2 Application should not be able to call the banking API without first obtaining further consent from the Portal User
      • However unless the OAuth2 Application was incorrectly configured originally (missing scopes), the application will not contain any code for calling the banking API
      • Only when the OAuth2 Application is upgraded might it need access to the banking API. At that stage the OAuth2 Application Administrator can include the BANKACCOUNT_READ into the global scope, by modifying the OAuth2 Application configuration
      • The OAuth2 Application should then redirect the user to the Authorization Service and it should list all the scopes that are included in the global scope, including the new one, so the Portal User can provide consent.



      • All scopes should be registered with a module namespace
      • When the OAuth2 Application Administrator assigns scopes to the OAuth2 Application, they will have the option to add global scopes/aliases. However if doing so the stored configuration should only contain scopes of the corresponding type (READ/WRITE) that were available at the time
      • When a scope is checked from an API, the aforementioned configuration for the scope will determine if the scope checker should take the namespace into account


          Issue Links



              tomas.polesovsky Tomáš Polešovský
              Participants of an Issue:
              0 Vote for this issue
              0 Start watching this issue




                  Version Package