It is generally possibile to use OAuth2 tokens generated by third party (external) authorisation systems in Apigee.
https://cloud.google.com/apigee/docs/api-platform/security/oauth/use-third-party-oauth-system
Note that by default Apigee SaaS (Apigee X) and Apigee hybrid hash all OAuth2 tokens and this behaviour can’t be altered for security.
https://cloud.google.com/apigee/docs/api-platform/security/oauth/hashing-tokens
For private cloud customers, the default storage of the OAuth2 tokens is cleartext. Optionally this configuration can be changed to one-way hash all tokens using the SHA-512 algorithm (or a lower strength, which is anyway not recommended), for security hardening of the storage of the tokens at rest (in addition to the DB encryption at rest at the file systems of the application database). Instructions are below:
https://docs.apigee.com/api-platform/security/oauth/hashing-tokens
and
https://docs.apigee.com/api-platform/security/oauth/use-third-party-oauth-system
Once tokens are hashed, they can’t be converted back into cleartext, hence they can’t be directly migrated from one Apigee Org to another Org in scenarios where these tokens are long lived (example multiple weeks or months). Best practice in OAuth2 is to have short lived tokens (15 minutes or less).
This presents a challenge for some customers. We will see below how to progress in this case.
One approach, which is recommended for short lived tokens is to disable hashing, wait until all hashed tokens have expired, then migrate the cleartext tokens to the new org and then enable hashing in the new org for newly minted tokens once the old tokens have expired.
If tokens are long-lived, the approach to be followed is necessarily different, and can leverage another feature embedded into the OAuth2 Apigee policy, the option to store foreign tokens into the Apigee OAuth2 token service.
To export tokens from a private cloud deployment, one needs to login into the noSQL datastore following the instructions provided in the Apigee Edge official troubleshooting guide for private cloud.
https://docs.apigee.com/api-platform/troubleshoot/troubleshooting-guide-pdf
The instructions on how to retrieve the schema and the list of the corresponding column families is also included in this same document.
The export can be performed using the same cqlsh command line client, for the corresponding column family (kms.oauth_20_access_tokens)
The following query Is an example of CQL that will retrieve the entries in this column family.
(NB: run the following query on a test system where you only have a handful of tokens, or change the query):
select * from kms.oauth_20_access_tokens;
You can use the following tool (CQLKIT) to export the column family into a CSV file:
https://github.com/strapdata/cqlkit
To import each individual token, you can use the approach described in the following repository which in short deploys an additional API proxy to the target Apigee organisation and will accept API calls that will store the hashed tokens in the local target DB storage as foreign tokens, thus overriding the internal Apigee mechanism to generate new UUIDs for the tokens locally. You can specify a different TTL for the newly inserted tokens by changing the corresponding policy configuration attributes.
Import OAuth2 access tokens into Apigee Edge:
https://github.com/gahana/edge-token-import
LinkedIn
Twitter
