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

Ankit Kumar commented on OLTU-159:
----------------------------------

OAuth spec states the following about Client Authentication - "If the client 
type is confidential, the client and authorization server establish a client 
authentication method suitable for the security requirements of the 
authorization server.  The authorization server MAY accept any form of client 
authentication meeting its security requirements."
The spec does not mandate how client authenticates with server, it specifies 
that a confidential client MUST authenticate with the authorization server.
This requirement is already handled by OAuthClient.java. When building an 
OAuthRequest as follows, if developer provides both client_id and client_secret 
then this class builds the same in the Form-URL-Encoded body request.
An example is as follows (pulled up from 
https://github.com/apache/oltu/blob/amber-0.10/oauth-2.0/oauth2-integration-tests/src/test/java/org/apache/amber/oauth2/integration/AccessTokenTestAuthCodeTest.java):
 
<code>
OAuthClientRequest request = OAuthClientRequest
            .tokenLocation(Common.ACCESS_TOKEN_ENDPOINT)
            .setGrantType(GrantType.AUTHORIZATION_CODE)
            .setCode(Common.AUTHORIZATION_CODE)
            .setRedirectURI(Common.REDIRECT_URL)
            .setClientId(Common.CLIENT_ID)
            .setClientSecret(Common.CLIENT_SECRET)
            .buildBodyMessage();
</code>

This will generate a body message as follows:
client_secret=test_secret&grant_type=authorization_code&redirect_uri=http%3A%2F%2Flocalhost%3A9002%2Fauth%2Foauth2%2Fredirect&client_id=test_id&code=known_authz_code

Notice that the body includes both client_id and client_secret. It is up to the 
server then to verify these credentials and then only proceed ahead (This is 
the same implementation in AuthZServer implementation class).



> Basic authorization in access token request
> -------------------------------------------
>
>                 Key: OLTU-159
>                 URL: https://issues.apache.org/jira/browse/OLTU-159
>             Project: Apache Oltu
>          Issue Type: Bug
>          Components: oauth2-client
>    Affects Versions: oauth2-1.0.0
>         Environment: Wildfly 8.1 with basic authorization on token 
> confidential endpoint
>            Reporter: ChristofBuechi
>            Priority: Critical
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> .h1 basic authorization on token endpoint for confidential clients
> First of all, I'm working with the actual OAuth 2.0 specification: 
> [http://tools.ietf.org/html/rfc6749]
> During our work on this specification we found the following problem in your 
> library:
> Intro: We are working with a confidential client and the authorization code 
> grant - flow.
> During the step of requesting an access token from the token endpoint, basic 
> authorization is required against the server. This step is done by the 
> library as describen in chapter 4.1.3:
> "If the client type is confidential or the client was issued client 
> credentials (or assigned other authentication requirements), the client MUST 
> authenticate with the authorization server as described in Section 3.2.1."
> You can see this also in the listet http request in this section 4.1.3
> You can fix that problem by adding the basic-authorization header in your 
> "OAuthClient.java", line 63. An example from my side:
> {code:java}
> headers.put("Authorization", base64EncodedBasicAuthentication());
> {code}
> with this method:
> {code:java}
>     private String base64EncodedBasicAuthentication() {
>         String up = "username" + ":" + "password";
>         byte[] base64 = Base64.encodeBase64(up.getBytes());
>         return "Basic " + new String(base64);
>     }
> {code}
> But you have to check where to get the username and password from. Those are 
> credentials which should be saved on the client-side, not resource owner!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to