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

[Ofer Nave <[e-mail]>]

> You’re right that these things aren’t defined in OAuth core itself, but
instead they’re defined in companion specs.

Awesome!  That's what I was hoping.

FYI - Up till now, I had only encountered the following relevant specs:

https://tools.ietf.org/html/rfc6749 — The OAuth 2.0 Authorization Framework
https://tools.ietf.org/html/rfc6750 — The OAuth 2.0 Authorization
Framework: Bearer Token Usage
https://tools.ietf.org/html/rfc6819 — OAuth 2.0 Threat Model and Security
Considerations
https://tools.ietf.org/html/rfc7009 — OAuth 2.0 Token Revocation
http://openid.net/specs/openid-connect-core-1_0.html
http://openid.net/specs/openid-connect-registration-1_0.html
http://openid.net/specs/openid-connect-discovery-1_0.html
https://tools.ietf.org/html/rfc7515 — JSON Web Signature (JWS)
https://tools.ietf.org/html/rfc7516 — JSON Web Encryption (JWE)
https://tools.ietf.org/html/rfc7519 — JSON Web Token (JWT)
https://tools.ietf.org/html/rfc7523 — JSON Web Token (JWT) Profile for
OAuth 2.0 Client Authentication and Authorization Grants
https://tools.ietf.org/html/rfc7033 — WebFinger
https://tools.ietf.org/html/rfc2617 — HTTP Authentication: Basic and Digest
Access Authentication

I'll add the two you mentioned to the list.

Any more useful specs I'm missing?  :)

-ofer


On Tue, Oct 13, 2015 at 4:36 AM, Justin Richer <[e-mail]> wrote:

> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
>