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 <odig...@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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
