Hi @kurtkanaskie @gonzalezruben @dchiesa1
Currently we have our app using one APIGateway product for signin flow with oauth2.0 password grant type & corresponding resources calls are using the access tokens provided as part of signinflow. Once the access token is expired, the refresh token flow is utilized to allow customer to perform certain operations in the mobile app without needing to enter credentials. Our business requirement is to see if there is way to perform a seamless cutover from current APIGateway product to apigeex without customers not needing to relogin with their credentials. ApigeeX will need to validate/allow current APIGateway generated tokens & generate tokens after the cutover. At some point we should be able to completely cutover to use only apigeex generated access/refresh tokens & generate tokens only via apigeex. Could you please help us provide a solution for this use case? Currently we have access token expiry of 3hrs & refresh token expiry as 1 year. Can we do a bulk upload of access/refresh tokens into apigeex cassandra database from other APIGateway database? Is that an option to keep the databases in sync for certain period to support the access/refresh token flow?
Hi @raghunathapalle , in general it is possible to make it a seamless transition for your users. There are multiple ways to realize this - you could call your old gateway from Apigee to do the validation for a transition period, you can have conditional flows in Apigee that could easily check from which system the token came from, and then route and process accordingly. You can also import all of the existing clients & credentials into Apigee, see docs for that here. It it would be useful to have a community session on this topic, just let us know, sounds like it could be useful!
sure. It makes sense to have a community session on this topic since there might be many orgs trying to adopt to migrate oauth flow to apigeex in a seamless fashion.
Hello @raghunathapalle,
Have you seen the following: https://github.com/kurtkanaskie/edge-to-X-oauth-token-migration
Yes it is scoped to an Edge/X migration, but can also be extended given the interfaces exposed in X to cache tokens.
Let me know your thoughts - thanks!