oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maciej Machulak <maciej.machu...@gmail.com>
Subject Re: Updating to oAuth 2-18
Date Wed, 13 Jul 2011 12:36:07 GMT
Hi Hoang/ Lukasz,

I agree with you guys. It'll be great to see contribution to Apache
Amber and making it compliant with the latest draft of OAuth2.

Also, as Lukasz suggested, it'll be better to create an additional
module for point 3 as client registration is based on a external draft
specification [1].

Cheers,
Maciej

[1] http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-02

On 13 July 2011 13:30, Łukasz Moreń <lukasz.moren@gmail.com> wrote:
> Hi Hoang,
>
> It's great to see your interest in contributing to the Apache Amber project.
>
> For me your explanation looks very good. I agree on points 1 and 2.
> Existing client registration in Amber is an implementation of the external
> draft. IMHO would be good to create additional module for point 3 to not mix
> both specifications.
> Feel free to submit patch then we will be able to review it and provide a
> feedback.
>
> Cheers,
> Lukasz Moren
>
> On Tue, Jul 12, 2011 at 7:59 AM, Hoang Minh Tien <
> minh-tien.hoang@fundp.ac.be> wrote:
>
>> Dear all,
>> As oAuth 2-18 specification is ready, I have some suggestions for updating
>> Amber to match with this specification. This is only my first experience
>> with Amber, so please give me your feedbacks as details as possible. Thank
>> you all in advance.
>> In my opinion, the changes should be performed on 3 main processes, mostly
>> related to validators:
>> i) Authorization request: there is no more code and token request type,
>> + The class CodeTokenValidator is obsolete and could be removed
>> + In OAuthTokenRequest.**initValidator remove the line put
>> ResponseType.CODE_AND_TOKEN in validators.
>> ii) Access Token request: the authentication between the client and
>> authorization enpoint could be happened earlier (Authorization header will
>> be shown in each request from client) in this case, the client_id or
>> client_secret will not be considered as required parameters in each access
>> token request as well as the redirect_uri which is also provided in
>> registration process.
>> + My suggestion are removing redirect_url as required parameter and adding
>> an authorization header check in AbstractValidator, in each constructor of
>> derived validator check the existence of authorization header in the
>> request, to decide to add client_id or client_secret as required parameters
>> or not. The validators involved are: AbstractValidator,
>> AuthorizationCodeValidator, PasswordValidator, AssertionValidator (only
>> grant_type is required), RefreshTokenValidator
>> + There is a newly added profile “client credentials” with
>> grant_type=client_credentials, which is reserved only for private client and
>> required only the validation of grant_type value. So we could
>> • Add a new validator class inherit from AbstractValidator, may be
>> ClientCredentialValidator with grant_type is set as required parameter.
>> • Add an enum to GrantType
>> • In OAuthTokenRequest.**initValidator, add this enum value in validator.
>> iii) Client registration: a new section for client registration is created
>> in oAuth 2-18 (the status is still Pending consensus) requires the custom
>> provide the custom type when perform registration. Could we consider of
>> adding it to existing client registration code?
>> Besides, I think we should change oauth_token to access_token in
>> BodyTokenExtractor.**getAccessToken and QueryTokenExtractor.**getAccessToken
>> of resource server because oauth_token is no more used.
>> Waiting for your opinion.
>> Thanks and kind regards,
>> Tien.
>>
>



-- 
Maciej Machulak
email: maciej.machulak@gmail.com
tel: +48 602 45 31 44
tel: +44 7999 606 767

Mime
View raw message