2012/2/6 Raymond Feng <[email protected]> > Hi, > > Adding a layer that supports the extensions of oAuth 2.0 (the spec already > mentions the extensions) is definitely desired. >
+1 > > Based on my usage/experience with Amber, we should probably go beyond just > the resource server that allows multiple types of token. I would like to > see some SPIs that allow the adopters of oAuth 2.0 to plug in their own > infrastructures. To name a few, > > * TokenGenerator (generating the tokens based on the token types) > * TokenManager (managing the tokens) > * Authenticator (authenticates the client and resource owners) > definitely +1 here too! > > We also need to have a way to wire the service providers into the oAuth > 2.0 base. Something like JAX-RS ContextResolver, Google Guice or the JDK > META-INF/services/ pattern can be used to connect the pieces together. > I agree and I'd be keen to use base JDK META-INF/services method to avoid introducing other dependencies. My 2 cents, Tommaso > > > Thanks, > Raymond > > On Feb 6, 2012, at 2:26 AM, Antonio Sanso wrote: > > > Hi *, > > > > just try to gain some opinion about AMBER-48 [0]. > > I hope you all agree a refactor is needed. > > Said that, I was wondering what you think on how to proceed. > > In my mind I can see two basic options: > > > > 1. Have the current resource resolver module as base. And have different > modules (that leverage resource resolver) implementing the specific token > type specification (e.g Bearer - resource resolver bearer, MAC ...) > > 2. Do the refactor keeping everything in the same module (existing > resource resolver) > > > > WDYT? > > > > Regards > > > > Antonio > > > > [0] https://issues.apache.org/jira/browse/AMBER-48 > >
