Restrict Access Token usage to the environment in which it was created?

[yassertaeima]

Is it possible to update the environment and/or oauth2 configuration to limit the access token validity to the environment that created it?

Assuming that Org "O1" has two environments "E1" and "E2"

Currently, if a token is created on environment "E1" with scope S1, we can use the same token to access products in the "E2" environment which allow scope S1.

I read the one post the suggests to limit the products into one environment and create two product, one for E1 and another for E2, but this is not feasible if we have a growing number of products and we have to make sure that whoever is designing the product is familiar with the oAuth Tokens and how they work and go against the normal product creation screen of ticking the check-boxes for the environments they need the product available on.

[DChiesa]

Hi Yasser,

yes, you can, with a little extra validation.

when issuing the token, add a custom attribute to the token that contains the current environment . The configuration of the OAuthV2 policy might look like this:

<OAuthV2 name='OAuthV2-GenerateAccessToken-CC'>
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn ref='flow.variable'>1800000</ExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.formparam.grant_type</GrantType>
  <!-- add this stanza -->
  <Attributes>
    <Attribute name='originating_environment'
               ref='environment.name'
               display='false'>UNDEFINED</Attribute>
  </Attributes>
  <GenerateResponse enabled='true'/>
</OAuthV2>

When validating the token, you keep your original OAuthV2/VerifyAccessToken policy. But augment it in the flow with a RaiseFault surrounded by a condition that checks that attribute, like this:

  <Request>
    <Step>
      <Name>OAuthV2-VerifyToken</Name>
    </Step>
    <Step>
      <Condition>NOT (accesstoken.originating_environment = environment.name)</Condition>
      <Name>RF-InvalidToken</Name>
    </Step>
     ...

[yassertaeima]

Thanks @Dino but this will require the developers of proxies to continuously add the RF-InvalidToken to every VerifyToken they create, which adds more complexity to code reviews.

We thought about encapsulating the VerifyToken into a shared flow as a customVerifyToken, but the <Scope>parameter cannot accept {variable} , which blocks that idea.

We also thought about using the same concept you listed but with a PreTarget Hook checking the condition for RF-InvalidToken, but this will still leave us vulnerable if the ProxyEndPoint performs some actions before it reaches the hook (service/flow callout for example).

For now, we will manage via a PreTarget Hook checking or a combination of separate Products/Scope/DevApp per environment, but it would be nice to have that "environment" check built into the Verify & Generate Token, something similar to a <TokenValidityScope>VHost|Env|Org

[dchiesa1]

Yes, I understand your suggestion. I'm sorry the existing approach isn't completely satisfactory for you.