issue with client credentials validation

[Liam Lynch <LL...@idbs.com>]

Hi amber devs -

I just ran into an issue using the OAuthTokenRequest to interpret a request. I noticed that for an authorization code grant type it automatically validates that the client ID and secret are there:

public class AuthorizationCodeValidator extends AbstractValidator<HttpServletRequest> {

    public AuthorizationCodeValidator() {
        requiredParams.add(OAuth.OAUTH_GRANT_TYPE);
        requiredParams.add(OAuth.OAUTH_CLIENT_ID);
        requiredParams.add(OAuth.OAUTH_CODE);
        requiredParams.add(OAuth.OAUTH_REDIRECT_URI);
        requiredParams.add(OAuth.OAUTH_CLIENT_SECRET);
    }
}


However in the spec passing the client ID and secret using BASIC authentication seems to be mandatory, whereas it is only optional to support passing the credentials via parameters in the body (and is not recommended):

http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-2.3.1

(Note previous v22 of the spec does not say BASIC is mandatory, but using the body is still not recommended:
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-2.3.1 )

So I was planning on using BASIC and this validation came as a surprise... :-)

Anything I've missed about this or any other suggestions?
Or if a bug do you think you are likely to fix for the first release?

I guess the options are (1) to offer a way to instantiate a OAuthTokenRequest that doesn't do this bit of validation (assumes this is taken care of elsewhere), this is simplest, or (2) get the details from the request authorization header to validate (and provide via getters).

Thanks - and thanks very much for all your work on this project!

Liam Lynch


The information contained in this email may contain confidential or legally privileged information. If you are not the intended recipient any disclosure, copying, distribution or taking any action on the contents of this information may be unlawful. If you have received this email in error, please delete it from your system and notify us immediately. Any views expressed in this message are those of the individual sender, except where the message states otherwise. IDBS takes no responsibility for any computer virus which might be transferred by way of this email and recommends that you subject any incoming E-mail to your own virus checking procedures. We may monitor all E-mail communication through our networks. If you contact us by E-mail, we may store your name and address to facilitate communication.

Re: issue with client credentials validation

[Antonio Sanso <as...@adobe.com>]

Hi Liam

On Feb 29, 2012, at 1:52 PM, Liam Lynch wrote:

> Hi amber devs -
> 
> I just ran into an issue using the OAuthTokenRequest to interpret a request. I noticed that for an authorization code grant type it automatically validates that the client ID and secret are there:
> 
> public class AuthorizationCodeValidator extends AbstractValidator<HttpServletRequest> {
> 
>    public AuthorizationCodeValidator() {
>        requiredParams.add(OAuth.OAUTH_GRANT_TYPE);
>        requiredParams.add(OAuth.OAUTH_CLIENT_ID);
>        requiredParams.add(OAuth.OAUTH_CODE);
>        requiredParams.add(OAuth.OAUTH_REDIRECT_URI);
>        requiredParams.add(OAuth.OAUTH_CLIENT_SECRET);
>    }
> }
> 
> 
> However in the spec passing the client ID and secret using BASIC authentication seems to be mandatory, whereas it is only optional to support passing the credentials via parameters in the body (and is not recommended):
> 
> http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-2.3.1
> 
> (Note previous v22 of the spec does not say BASIC is mandatory, but using the body is still not recommended:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-2.3.1 )
> 
> So I was planning on using BASIC and this validation came as a surprise... :-)
> 
> Anything I've missed about this or any other suggestions?
> Or if a bug do you think you are likely to fix for the first release?


at the first glance looks a bug to me. How about open a Jira ticket so we can move forward?

Regards

Antonio

> 
> I guess the options are (1) to offer a way to instantiate a OAuthTokenRequest that doesn't do this bit of validation (assumes this is taken care of elsewhere), this is simplest, or (2) get the details from the request authorization header to validate (and provide via getters).
> 
> Thanks - and thanks very much for all your work on this project!
> 
> Liam Lynch
> 
> 
> The information contained in this email may contain confidential or legally privileged information. If you are not the intended recipient any disclosure, copying, distribution or taking any action on the contents of this information may be unlawful. If you have received this email in error, please delete it from your system and notify us immediately. Any views expressed in this message are those of the individual sender, except where the message states otherwise. IDBS takes no responsibility for any computer virus which might be transferred by way of this email and recommends that you subject any incoming E-mail to your own virus checking procedures. We may monitor all E-mail communication through our networks. If you contact us by E-mail, we may store your name and address to facilitate communication.