oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stein Welberg (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OLTU-12) [oauth2-resourceserver] resource access validation always fails if there is more than one parameter style defined
Date Wed, 23 Sep 2015 19:43:04 GMT

    [ https://issues.apache.org/jira/browse/OLTU-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14905114#comment-14905114

Stein Welberg commented on OLTU-12:

Good question. I haven't done anything with this since may 2013.. I also haven't send Ben
an email.

However, I wonder whether we should solve this issue since it's quite a corner case if an
access token is supplied in two ways. I would actually strongly recommend to only use the
header method and deprecate the other two since they are less secure. The spec also states
that you MUST support the authorization header approach and might support the other two methods.

> [oauth2-resourceserver] resource access validation always fails if there is more than
one parameter style defined
> -----------------------------------------------------------------------------------------------------------------
>                 Key: OLTU-12
>                 URL: https://issues.apache.org/jira/browse/OLTU-12
>             Project: Apache Oltu
>          Issue Type: Bug
>            Reporter: Ben Noordhuis
>            Assignee: Stein Welberg
>         Attachments: AMBER-15-adding-test-patch.txt, amber15.patch
> Why? Because the headers, body and query validators are tried in turn in OAuthAccessResourceRequest.validate().
Two of the validators will throw and the second exception is re-thrown unconditionally outside
the loop.
> I'm not sure what the right approach here is. I wrote a preliminary patch[1] but one
edge case is that a request with a 2.0 query token and 1.0 authorization header will slip
> Checking for OAuthError.TokenResponse.INVALID_REQUEST doesn't work either. BodyOAuthValidator
always throws that when the request isn't application/x-www-form-urlencoded (i.e. almost all
the time).
> [1] https://github.com/bnoordhuis/amber/commit/b4df9c2
> [2] curl -v -H 'Authorization: OAuth abc123,oauth_signature_method="HMAC-SHA1"' http://localhost:8080/?oauth_token=abc123

This message was sent by Atlassian JIRA

View raw message