-
-
Notifications
You must be signed in to change notification settings - Fork 304
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible issue with mirroring back the query params that were passed from authorization server #141
Comments
Thanks for the detailed report @menisy, I will need to do some looking into things as I'm not sure off the bat what the correct behavior is. I'd be willing to review a PR and evaluating the risk of any changes if you have a suggestion in the short term |
@BobbyMcWho thanks for the prompt response. I have something in mind, I will try to issue a PR soon. |
@BobbyMcWho please have a look here whenever you have some time |
I'm somewhat surprised that the extra params are causing issues, because I've used omniauth-okta before, and okta has some fairly strict redirect uri matching if I recall correctly |
@BobbyMcWho according to omniauth-okta's implementation, they're overriding the The spec is very clear that the |
With this update from Doorkeeper, existing authorization flows stopped working. This is no longer the case since this update on Doorkeeper was reverted.
However, it seemed to me that there is a strange behaviour when I was debugging to see why this was no longer working.
A couple of
pry
's later I figured out what's going on. I will use an example as it's a bit complicated to explain:Resource server on
localhost:3000
Authorization server on
localhost:5000
redirect_uri
on Doorkeeper (authorization server) side is:http://localhost:3000/auth/some_provider/callback
http://localhost:5000/oauth/authorize?client_id=some_client_id&&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fauth%some_provider%2Fcallback&response_type=code&state=some_state
http://localhost:3000/auth/some_provider/callback?code=some_authorization_code&state=some_state
redirect_uri
using thiscallback_url
method defined inomniauth
which adds therequest.query_string
to thecallback_url
. So the code exchange request becomes:POST http://localhost:5000/oauth/token
with params:and this is where it is questionable whether the
code
andstate
should be replied back to the authorization server as part of theredirect_uri
even though they didn't originally exist in the request phase. And this is where the reverted update was facing an issue as it couldn't fully match theredirect_uri
with these extra query params against the one(s) defined on the authorization server during registration of the client.This is the source of it in
omniauth
, I honestly did not dive deep enough in the spec to know what is the expected behaviour, however, this behaviour doesn't look correct.The text was updated successfully, but these errors were encountered: