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

I think what you’re talking about is reasonable, but I also think that you don’t need to invent anything. You’re right that these things aren’t defined in OAuth core itself, but instead they’re defined in companion specs. Most notably you have:

 - JWT (RFC7519): a structured token based on JSON and JOSE that lets you carry information inside the token itself. This can be signed and/or encrypted. The RS needs to understand the token format, but the client can still be oblivious to it and still function just fine. https://tools.ietf.org/html/rfc7519
 - Introspection (soon to be RFC7662, it’s in the final stage of editing as we speak): a simple protocol that allows an RS to query the AS with a token to see if it’s any good and what it’s good for. This returns a JSON document describing the token. https://tools.ietf.org/html/draft-ietf-oauth-introspection
 - UMA’s resource set registration (from Kantara, version 1.0.1 in final review right now): This is part of the User Managed Access (UMA) protocol and it lets an RS register a set of resources at the AS. This is very similar to what you’re describing below in terms of registering scopes for each resource server. https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1.html

Combining these specs together you’ve got pretty much what you’re after, as best as I can tell. There are a number of implementations of all of these, including the project that I help run, MITREid Connect. https://github.com/mitreid-connect/ Our server issues signed JWTs, provides token introspection, and lets resource server owners register their scopes to expose to users through a simple web UI. 

 — Justin

> On Oct 13, 2015, at 12: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