Re: [OAUTH-WG] Auth Server / Resource Server Coordination

> Isn't the whole idea of the auth server/resource server separation in
OAuth 2.0 so that one auth server can govern multiple resource servers?

The spec certainly allows for that, but it stops short of:

1) Defining an Access Token structure that both parties can understand.
2) Any standards whatsoever about any other communication or coordination
between the AS and RS.

It's outside the scope of the spec, and so it falls to the implementer to
make those decisions.  This is my first attempt to do so.

The design I propose is very simple and yet seems to accomplish the goal
sufficiently.  The way OAuth2 is designed, authorization comes down to a
simple set of scope booleans, and that's very easy to model and delegate.
There's really no reason everyone should have to be reinventing this.  The
protocol for AS/RS coordination almost seems to write itself.  I'm
surprised an extension doesn't exist yet for this -- which is why I'm
asking for a sanity check, just in case I've missed something.

-ofer

On Tue, Oct 13, 2015 at 12:36 AM, Jim Manico <jim@manicode.com> wrote:

> This seems like a reasonable approach. Isn't the whole idea of the auth
> server/resource server separation in OAuth 2.0 so that one auth server can
> govern multiple resource servers?
>
> --
> Jim Manico
> @Manicode
>
> > On Oct 13, 2015, at 6:13 AM, Ofer Nave <odigity@gmail.com> wrote:
> >
> > I know the OAuth 2.0 RFC doesn't specify any standards for coordination
> between the Authorization Server and the Resource Server, as it's generally
> assumed that both will be owned or operated by the same entity.
> >
> > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a
> feature to make it easy for other API developers to delegate to me the
> responsibility of handling the auth grant process and issuing access tokens.
> >
> > It seems to me that a simple version of this could be easily done by:
> >
> > 1) Defining an Access Token format that contains within it everything a
> Resource Server will need to validate it and determine the level of access
> granted (list of scopes, expiration datetime, HMAC signature using a shared
> secret).
> >
> > 2) Providing a means (basic web UI) for Resource Server owners to
> register a set of scopes for their service, along with user-understandable
> descriptions of each to display when they arrive at my Authorization
> Endpoint.
> >
> > While I've read the relevant RFCs, I'm new to the OAuth domain, and
> would appreciate any feedback. Is this a stupid idea?  Is this a good idea,
> but redundant with another standard I'm not aware of?
> >
> > -ofer
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>