-
Notifications
You must be signed in to change notification settings - Fork 326
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
Specific redirect URI for each OP #291
Comments
There's an existing mitigation mechanism in place for that: one can add So you'd register: where This mechanism was one of the proposed solutions that were determined by the OAuth working group when analyzing this attack. |
Ok, i registered : But the authorization request send by mod_auth contains this static redirect_uri parameter : So this redirect_uri value doesn't match exactly with the one registered in my OPs and the authorization request is refused. How can i configure mod_auth to build dynamicaly the good redirect_uri param in the authorization request? |
It requires matching on the OP side to ignore request parameters. |
But in the OAuth2 / OIDC specs, the authorization request validation (OP side) specify that the redirect_uri param must match exactly with the one registered. Don't you think that mod_auth can set this param dynamicaly to respect specs? I think for example : |
The query parameter may be ignored but if your OP does not support that then there's no alternative currently. I'll keep this as a feature request but prioritizing it would require a commercial discussion. |
used in multi-provider setups to mitigate the IDP mixup attack by setting "issuer_specific_redirect_uri" in the .conf file; this will add a parameter "iss" to the redirect URI with the url-encoded issuer value; thanks @remi-cc Signed-off-by: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
In a167873 I've added the option to add the "iss" parameter to the redirect URI in multi-provider setups. This is less preferred than adding it in the redirect URI path but a lot easier to implement and backwards compatible. Would you be able to verify this? |
Let me verify it with pleasure |
I realized that OpenID Connect indeed requires simple string comparison as the redirect URI matching algorithm and as such the existing mitigation is not enough by spec though it may work against various providers, e.g. Google was tested successfully earlier. And since the spec allows for a query parameter to the Redirect URI that must be retained (https://tools.ietf.org/html/rfc6749#section-3.1.2), any spec-compliant Provider should now work with the new mitigation implementation. FWIW: binary packages are available from http://mod-auth-openidc.org/download/?C=M;O=D; you'll need |
I installed binary packages and set up "issuer_specific_redirect_uri" in the OP.conf file. Anyway, when i intercept myself the authorization request, mod_auth_openidc adds in the redirect_uri parameter the issuer as URL encoded query parameter. Like you said, OP spec-compliant should accept it, which it's not the case of WSO2 IS product. Thanks for your great work. |
Hi, I am an architect from the WSO2 Identity Server product. Interesting discussion! WSO2 IS respects the query parameters in the redirect_uri sent by the client - and once you configure it in WSO2 IS with the same. The issue here seems to be from mod_auth_openidc - it does URL encode the redirect_uri, before placing it in the request. Ideally if you just place the url as it is (and expect the browser to do the URL encoding this will work fine). So the issue here is in WSO2 IS when you define the redirect_uri, you cannot define it as an URL encode format - because of the characters like % - and it's not allowed. So, I do not think this is a OP spec-compliant issue... Anyway thanks for bringing this up... Thanks & regards, |
Thanks @prabath ; the point is that the query parameter - which is a URL in itself - needs to be preserved as part of the callback to the RP, not as part of the authorization request to the authorization endpoint of the OP. Hence url-encoding is required for this parameter just like it is for the others, e.g. to preserve spaces in the Note that even when including the |
Hi @zandbelt, This is a quick test I did with WSO2 IS.. When you send the following authorization request (where the iss value is not URL encoded, but browser will do that) - and IS will completely URL-decode it. This will return to the following URL (preserving the query parameter).. http://127.0.0.1:5000/?iss=http://test.com&code=d64afedb-2c9d-3f5b-ac32-890634b30f57 Now, RP will completely URL decode the request from the browser. I think the issue is, if you send the initial request from the mod_auth_openidc , then it places the URL as the following, where part of it is URL encoded by the module and expects the rest to be done by the browser.. Also from WSO2 side, we will consider allowing % character when defining the redirect_uri at the OP side in our next release (since its a valid character) - so you can define the redirect_uri there as http%3A%2F%2Ftest.com instead of http://test.com. Thanks & regards, |
I'm not sure which version you used but mod_auth_openidc always url-encodes the value of the |
In my point of view (but i'm not a web expert), the doubly URL-encoded for iss query parameter in the redirect_uri seems to be the right thing to do. |
@remi-cc yes - I think the issue is the restriction we enforce on while defining the redirect_uri at the IS side. Yes - we will fix that for IS 5.4.0. |
@remi-cc you may be able to hack around the url-encoding in your own fork for the time being and try to achieve what @prabath describes until 5.4.0 is out but that comes with a warning: it is not really straight-forward since the module automatically encodes all parameters and values so you'd have to make an exception for the redirect URI. |
@remi-cc I have validated this with my own OP so I'm closing this. You can re-open if needed for some reason. |
Dear Mr Zandbelt,
I have a new feature request for security reasons.
In order to mitigate Mixup-Attack, the OpenID foundation advise to specify a redirect_uri different for each OP, like :
www.myapacheserveur.com/callback1 for the first OP;
www.myapacheserveur.com/callback2 for the second OP.
Then, RP must verify that the authorization response has been received on the specific URI associated with the OP of the user session.
All informations are available on OpenID Foundation website :
http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/
"Register a different redirect URI for each OP, and record the redirect URI used in the outgoing authorization request in the user’s session together with state and nonce. On receiving the authorization code in the response, verify that the user’s session contains the state value of the response, and that the redirect URI of the response matches the one used in the request."
Do you think that you can implement this?
The text was updated successfully, but these errors were encountered: