Make `redirect_uri` optional when generating an authorization URL.
bunchesofdonald opened this issue · 4 comments
In our integration with WorkOS, in many cases, we're letting the client set the redirect_uri but in some cases it doesn't know and in those cases we'd just like to use the default redirect_uri. However it appears that the REST API and the get_authorization_url method require a redirect_uri be provided.
Would it be possible to make the redirect_uri optional and fallback to the default as defined in the WorkOS admin dashboard? The other option is for us to maintain which is the default both in WorkOS and in our code and we'd like to avoid that duplication.
Hey there! We require redirect_uri to be passed in so that the behaviour is explicit with every call. We compare the passed in uri against the registered ones on the dashboard as a security check, and if someone changes the default redirect_uri on the dashboard it can have unintended consequences if we didn't have it passed in explicitly.
Can you give more detail on when you wouldn't have/know the redirect_uri ?
Hi @ameesha, thanks for the response!
I wouldn't say it's about whether or not we know what the URL is, it's about the duplication of having the default set in WorkOS and also having to know that same default on our side when generating the authorization urls. If we change the default we have to change it in WorkOS and in our codebase, when it'd be nice for WorkOS to just be able to handle that on its own since it has all of the data.
Hey @bunchesofdonald, can you explain a bit more on why you need to store the default on both your systems and WorkOS?
The redirect_uri that you pass in when generating an authorization URL doesn't need to be the default WorkOS one, it just needs to be registered with WorkOS.
And for IdP-initiated, if you want to overwrite the WorkOS default you can do so with the steps to configure the RelayState defined here -- that page also has a couple other options if configuring the RelayState isn't feasible.
Let me know if that helps!
Thanks @ameesha! I think we can close this out.