oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Sanso <asa...@adobe.com>
Subject Re: Change in authorization server
Date Tue, 26 Mar 2013 13:53:55 GMT
Hi Stein,

thanks a lot for bring this up.

As a general rules of thumb I do agree with Simone about backward compatibility. Since is
already broken let's try to improve as many things as we can for next release.
I will have some other proposals but I will write a separate mail for it.

On Mar 24, 2013, at 2:16 PM, Stein Welberg wrote:

> Hi Guys,
> 
> Since Simone made a good remark in the another thread (changing/updating groupId/artifactId)
that we are breaking Amber backwards-compatibility, I would like to suggest another change.
I would also like your opinion about the way to implement it.
> 
> Currently the Oltu Authorization server implementation is not spec compliant regarding
the support for Basic Authentication (see OLTU-5 and OLTU-16). According to the spec section
2.1.3 [0] the authorization server must support basic authentication. I am currently trying
to figure out a way to support both unauthenticated requests and authenticated requests (either
using basic authentication or not). The unauthenticated requests will not have the client_secret
parameter since they possibly don't have a client_secret.
> 
> The current setup of the validators does not allow us to dynamically make a param (e.g.
the client_secret) required or optional based on some parameter. The validators are added
in the OAuthTokenRequest so this is the place to create the distinction between an unauthenticated
request an an authenticated request. Without doing a real big refactoring of the validators
we have two options to support both authenticated and unauthenticated requests:
> 
> 1. One way to do this is by creating another OAuthTokenRequest class that accepts only
authenticated requests (the OAuthAuthenticatedTokenRequest class). The plain OAuthTokenRequest
class then only handles unauthenticated requests.
> 
> 2. The second option is to use a boolean in the constructor of the OAuthTokenRequest
class to indicate whether we want Oltu to treat the request as an authenticated request or
not. I would suggest that we enforce authentication by default and that adding the boolean
to the constructor would make it possible to also support unauthenticated requests (secure
defaults).
> 
> My preference goes to the first approach where we create a separate class purely for
authenticated requests since it creates more readable code. (code with booleans in a method
tend to get quite unreadable quickly!)
> 
> I would like to have your opinions since this is quite a change in the API for the developers
that are going to use Oltu to create an authorization server!

I remember the discussion in OLTU-5 and after thinking about it I think we can go with the
2 different classes (so solution 1. above) as long as :

- we document it
- it is possible to use both the OauthTokenRequest and the  OauthAuthenticatedTokenRequest
together if needed.

WDYT?

Regards

Antonio


> 
> Thanks.
> 
> Regards,
> Stein
> 
> [0] http://tools.ietf.org/html/rfc6749#section-2.3.1


Mime
View raw message