Add redirect_uri and and response_type to success callback
Prior to this, the success callback provided three things:
an object that holds the session function for creating a new token and redirecting back with the token in the hash, The input that holds the provider, the tokenset and the oauth client the raw request This PR adds the redirect_uri and response_type to the first object alongside the session function. It also tries to get these values from the query params as an alternative to the getCookie helper.
The reason I'd like this to be added is because the session function is doing too many things for my usecase. In a Next.js application, I have an API route that acts as my final callback to the front end. This API route is server side and does not expose the hash on the Request object. The flow is like this:
SST Auth lambda redirects to www.frontend.com/callback#access_token=abcd1234 ----> Next API Route picks up the request and loses the access_token because the hash is never sent to the server. I believe that is just part of the HTML spec.
If we can also expose the redirect_uri and response_type here, I can do the redirect in my app without using the session function. I'd be able to append the access_token as a query parameter which does persist between across to the server.
The alternative to this PR is changing how the session function works and instead of appending the access token and state to the hash, we append it as a query parameter.
Is there an issue related to this? If not let's open one so I can assign it to have this looked at.
Is there an issue related to this? If not let's open one so I can assign it to have this looked at.
@jayair I didn't create an issue because I figured it's not exactly a bug - just a nice to have for my own setup but I can create an issue now
if you're receiving the access token to a server side function you should change your response_type to code - that will give back a code in the query parameter that can be exchanged for an access token
sst auth follows the oauth spec
Yeah you're right, response_type='code' works 👍