oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Feng <enjoyj...@gmail.com>
Subject Re: Resource Server refactor
Date Mon, 06 Feb 2012 22:04:26 GMT
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


Mime
View raw message