Oauth2.0 migration from apigee edge to apigee-x without path change

[Satire]

Hello All,

I need help on oauth migration from apigee edge to apigee-x and don't want to change the path for consumer. As I am doing phase wise migration , the traffic will go to apigee-x for one environment and environment groups and the rest will go to apigee edge and for that I am having F5 routing rule setup.

I want to deploy same oauth proxy both in edge and x and obviously the path will be same so that my consumers will not do any kind of changes from their side to hit the oauth proxy for generating and verifying the token.

Path example: generic/platform/v1/oauth2/token, generic/platform/v1/oauth2/verify

[AlexET]

Hello @Satire, thanks for your question! I just wanted to acknowledge it and let you know we’ll make sure it gets noted. We also invite others in the community to chime in and help out.

In the meantime, you may find this recent article helpful: Introducing the Apigee Migration Assessment Tool: Your roadmap to a smooth transition.

Thanks for being part of the community!

[dchiesa1]

---

@Satire wrote:

I want to deploy same oauth proxy both in edge and x and obviously the path will be same so that my consumers will not do any kind of changes from their side to hit the oauth proxy for generating and verifying the token.

---

So what's the obstacle?   I don't see a question in your post.

Maybe you're asking "Will this work?" and "what are the catches?" 

And you're right to ask.  

Here's what I mean: Imagine this scenario. A client app sends in a request-for-token. F5 routes it to Apigee Edge.  Edge creates a new token and sends it back.  The client then sends in the token with a new request.  F5 receives it and decides "I'm going to route this to Apigee X, because Satire has configure THIS particular path to be handled by Apigee X."  Apigee X receives the request. The token is completely unknown to Apigee X. Apigee X rejects the call with "invalid OAuth token." 

??

You cannot have a phased migration, unless Edge and X share tokens. 

One way to do this is , for every new token request to be performed in both Edge and X.   In the above scenario, before Edge sends back the new token to the client, it first must send the token to X, which will "import" the token and store it.  Then, the client can send the token to either Edge or X, and the token will be valid.  In my experience, customers going through this migration use Apigee X to create all new tokens. They create a special path in F5 at the very beginning , and any request to /OAuth/token is sent to X.  Then X creates a new token and shares it with Edge.  And then in subsequent calls, F5 can route any inbound call, any way it likes. 

There are some issues with this!  Invalidating a token or revoking a token, also must be synchronized across Edge and X.   You need to synchronize lifetimes of tokens.  You cannot perform rate limiting on a token-by-token basis.  and so on . but if you can live with these caveats , this might work fine.