Oauth2.0: Validity of access tokens across environments

Let's consider the following scenario:

  1. Generate an Oauth2.0 access token using any of the grant types

    /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>'

  2. Execute the API with the access token generated above in “test” environment

    /code curl https://<org-name>-test.apigee.net/<api>/v1/<resource> -v -H 'Authorization: Bearer <access-token>'

  3. Execute the API with the same access token in “prod” environment

    /code curl https://<org-name>-prod.apigee.net/<api>/v1/<resource> -v -H 'Authorization: Bearer <access-token>'

  4. Interestingly, we notice that both steps 2 and 3 are successful. That is, the same access token was valid across two different environments “test” and “prod”

Now, this raises a few questions such as

  1. How is the token generated in test environment (refer to curl command in Step 1 above) valid in prod environment ?
  2. On the other hand, if it is valid to use the same access token in multiple environments. Then, what if we need to make the “prod” environment more secure and want to use a different access token. Is there some way to use different access tokens in different environments ?

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,

  • DeveloperApp is generally associated with one or more API Products and contains the Client_ID/Client_Secret.
  • API Product is associated with an API Proxy. API Product allows API access to end users for one or more environments like “test”, “stage”, “prod” etc.

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 –

  1. Create a new API Product “SampleAPI-Product-Prod” and associate with API Proxy SampleAPI and allow the API access only for the “prod” environment.
  2. Create a new DeveloperApp “SampleAPI-App-Prod” and associate with the API Product “SampleAPI-Product-Prod”.

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.

Comments
suninshah
Explorer

@AMAR DEVEGOWDA

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?

Version history
Last update:
‎07-14-2015 05:44 AM
Updated by: