Hi, Adding a layer that supports the extensions of oAuth 2.0 (the spec already mentions the extensions) is definitely desired.
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) 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. 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
