Getting back to the original protected url on oauth flow

[saul-data]

What is the best way to get back to the original url?

We have successfully implemented Fusionauth oauth flow. The only part that we aren't sure about is how to get back to the original url where the user requested but wasn't logged in.

I have gone through the Gatsby & PKCE example (https://fusionauth.io/blog/2020/06/25/using-oauth-and-pkce-to-add-authentication-to-your-gatsby-site) and all the documentation and I couldn't find any reference on how to do this.

Description

Intended flow: I am on a page and my token expires or navigated to a protected route page and I am not logged in. I need to login again.

1. User navigates to protected page /protected (React app)
2. Redirect to generated login url oauth/login (on Fusionauth service)
3. Successful login, redirect to redirect uri: oauth/callback (Golang back end service)
4. Oauth/callback exchanges code for token
5. ** this is the part that isnt quite clear - we can redirect to a specific page but the protected page could be any protected page that was originally requested i.e. /protectedpage2 /protectedpage3 etc

Is there a way the /protected url is remembered throughout the flow? Then at the end go back to that original url?

[robotdan]

There are different strategies you can use to accomplish this behavior. One option is to encode the URL in the state parameter, and then decode it once you hit the oauth/callback endpoint and then perform a final redirect.

You could also drop a cookie before you redirect to FusionAuth, and then pick it back up when you hit the oauth/callback URL.

Or, if you have a finite number of URLs, you could just add this value as part of your redirect_uri paramter, and register each possible value with FusionAuth as authorized redirect URLs.

[saul-data]

This is very helpful helpful thank you. I would suggest putting the state parameter suggestion in your documentation, others might find it useful too. :)

On Wed, 29 Jul 2020 at 16:39, Daniel DeGroff notifications@github.com wrote:

There are different strategies you can use to accomplish this behavior. One option is to encode the URL in the state parameter, and then decode it once you hit the oauth/callback endpoint and then perform a final redirect.

You could also drop a cookie before you redirect to FusionAuth, and then pick it back up when you hit the oauth/callback URL.

Or, if you have a finite number of URLs, you could just add this value as part of your redirect_uri paramter, and register each possible value with FusionAuth as authorized redirect URLs.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/FusionAuth/fusionauth-issues/issues/774#issuecomment-665739676, or unsubscribe https://github.com/notifications/unsubscribe-auth/APGDMKOP3YBPXEE7U4RQJPDR6A7CZANCNFSM4PHSZPWQ .