A slight adjustment: See inline. On 24 mrt. 2013, at 14:16, Stein Welberg <[email protected]> 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. Instead of creating a new class that handles authenticated token requests, I would suggest to create a new class with the name OAuthnUnauthenticatedTokenRequest and change the behavior of the OAuthTokenRequest class to only support authenticated requests. This also with regards to encourage sensible (secure) defaults. Regards, Stein > > 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! > > Thanks. > > Regards, > Stein > > [0] http://tools.ietf.org/html/rfc6749#section-2.3.1
