Handling 302 redirect uri resposne in the Browser

Not applicable

Hi,

My back end target service run only on the browser and return 302 log in URL (

https://login.qa.eu.nissan.biz/nidp/app/login?id=B2B&sid=0&option=credential&sid=0&target=https://lo...

) with query string parameters. It is expected that - the response will automatically open the log in page from where the user session start and continue carry on.

Is any way to handle the 302 response and push the response to the Browser?

1 5 2,717
5 REPLIES 5

Not applicable

Not applicable

Based on the URL it seems that you're trying to implement Auth code 3-legged OAuth 2.0. HTTP response codes are precisely what you described, a redirect from the browser to the login resource on the server. So in your case, the login resource should have the implementation on how to handle the request and exchange the authorization code for an access token. The App developer does this implementation.

One important observation: I noticed that the URL contains the secret in it. It is strongly recommended that secrets and sensitive data must not be visible and be kept secret at all times. In your case, this piece of information should be managed by the App Developer on the server side fully protected from anyone, except the app to handle the auth code exchange.

@Kuldeep Bhati :

This is our flow -

when back end service call from the Browser , it is redirect to Log in page with 302 status.

But when call the back end service through Apigee Edge , it is return 302 with URL - which when paste on the Browser, it will not open the log in screen.

@Diego Zuluaga : Yes, you are right, this is Auth Code 3- legged implementation.

In Apigee Edge - When I hit the back end service, it is returning the log in page URL with some parameters which in turn I returned to the client. When client paste the response in the Browser, it is not working.

When I call the the above - back end service from the Browser, it is working fine but when calling from the Apigee , it is not working.

If you are trying to intercept the callback from the login service, check the response it is sending, if it is like https://api-test.nissan-europe.com/identity/v1/callback#code=123456 the Edge proxy will not match. It needs to be either via a query param or (e.g. callback?code=123456 or POST callback (formparams).

If you are attempting to redirect the App to the login page you will need an https://api-test.nissan-europe.com/identity/v1/authorizes which uses an Assign Message to redirect to the login page with the callback and the client ID set to the value that has been registered with your OpenID Connect Provider (OP). Also the callback specified in the login call must be registered with the OP.