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

> The RS needs to understand the token format and needs to trust the AS.

I'm not too concerned about that because the people who would be using my
service to handle auth for their API are mostly going to know me
personally.  (It's a community-specific service.)  And my code will be open
to them for review.

> You can use a JWT (a common choice) as your token format which makes that
part fairly easy.

I was wondering about that, actually, as I've never had to design a token
format.  I wasn't too worried, because it seems to me that even a simple,
obvious structure would be sufficient for the task (pick an object notation
like JSON or just a separator like pipe, put the fixed fields like
signature and expiration first, and then the rest are scope strings).
However, I agree it's generally wise to reuse existing, proven standards.

I learned about JWTs while studying OAuth2, and they do seem both
interesting an appropriate.  But they're also generalized, right?  As in,
not specific to OAuth 2.  Even this RFC about using JWT with OAuth2 doesn't
actually discuss, for example, how to encode a list of scopes within the
JWT:  https://tools.ietf.org/html/rfc7523

So, is there any kind of standard for an OAuth2 Access Token specifically
that addresses this need?  If not, I'll probably just build on top of JWT
since it's the closest.

> You do have decisions to make on whether you use symmetric crypto or PK
there.

That's another thing I was pondering -- simple shared secret, or require
generated a private/public key pair.

The asymetric form is a little more complicated in terms of the user
experience.  Is there a practical reason to prefer it?

-ofer

On Tue, Oct 13, 2015 at 12:20 AM, Bill Mills <wmills_92105@yahoo.com> wrote:

> You're generally right on track.  The RS needs to understand the token
> format and needs to trust the AS.  You bring in all the "hwo do 2 entities
> maintain a trust relationship in computing thing" here, because the RS
> needs to trust the AS.  You can use a JWT (a common choice) as your token
> format which makes that part fairly easy.  You do have decisions to make on
> whether you use symmetric crypto or PK there.
>
>
>
> On Monday, October 12, 2015 9:14 PM, 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
>
>
>