oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Moreń <lukasz.mo...@gmail.com>
Subject Re: Updating to oAuth 2-18
Date Wed, 13 Jul 2011 12:30:43 GMT
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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message