Let's consider the following scenario:
/code curl https://<org-name>-test.apigee.net/<api>/v1/generateaccesstoken -v -d 'grant_type=password&client_id=<id> &client_secret=<secret> &username=<username>&password=<password>'
/code curl https://<org-name>-test.apigee.net/<api>/v1/<resource> -v -H 'Authorization: Bearer <access-token>'
/code curl https://<org-name>-prod.apigee.net/<api>/v1/<resource> -v -H 'Authorization: Bearer <access-token>'
Now, this raises a few questions such as
This article aims to explain the validity of access token across multiple environments and in the process answers the above questions.
First of all, let's look at the Step 1 above. The URL in the curl command does indicate that we are generating the access token for “test” environment. However, it doesn't mean that the access token is valid for the “test” environment and not valid for other environments. Now what does that mean ?
The validity of the access token is not determined by the fact in which environment was the access token generated. Rather, it is determined as explained below:
As you might know in Apigee Edge,
If the API Product allows access for multiple environments (let's say “test”, “stage” and “prod”), then the access token generated will be valid across all those environments. Likewise, if the API Product allows access only for one environment (let's say “prod” environment), then the access token generated will be valid only for that specific environment.
Essentially that means the access token can be generated in any environment. But it's validity is based on the fact for which environments, the API Product allows API access to the end users.
Let me explain with the help of an example:
Example 1 – Same access token valid for multiple environments
Org Name
Sample
Let's create the API Proxy, API Product, DeveloperApp, Developers as follows:
API Proxy
SampleAPI
Product
SampeAPI-Product-AllTest
Note: This Product is associated with SampleAPI and allows access for “test”, “dev” and “stage” environments.
DeveloperApp
SampleAPI-App
Note: The SampleAPI-App contains the Client_ID – “id_sample” and Client_Secret - “secret_sample”
Developer
SampleAPI-User (sampleuser@apigee.com)
Let's generate an access token using the below command:
/code curl https://sample-test.apigee.net/Oauth-API/v1/generateaccesstoken -v -d 'grant_type=password&client_id=id_sample&client_secret=secret_sample &username=sampleuser@apigee.com&password=passw0rd'
Let's say the access token generated is “access_token_alltest”.
As seen above, the access token has been generated by running the curl command in test environment. However, you can use this access token and run the SampleAPI calls in any of the “test”, “dev” and “stage” environments. This is because the API Product “SampleAPI-Product-All” allows access to SampleAPI for all these environments, so the access token is valid across all these environments.
Example 2 – Access token valid for a specific environment
Now, if we want to ensure that an access token is valid only for a specific environment (let's say “prod” only), all we have to do is –
In summary, the access token can be valid for multiple environments and/or you can make the access token valid only for specific environment. It means you can use the same access token in multiple environments and you can use different access tokens in different environments.
This is fine when you have access to Apigee edge and are able to create API Products that are segregated in this manner. What happens when you are exposing the API Products through a Developer portal and your consumers are adding them to their Apps? In this case if they add products from multiple environments to the app, they will be able to call the associated API using the same token - correct? Is there any way of limiting what is available then - short of customising the developer portal?