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

[Ofer Nave <[e-mail]>]

> One advantage of requiring introspection is the easy support of
revocation without having to create a specific API to check whether a token
is revoked: you just introspect the token and directly know whether the
token is valid or not, and if it's valid you get its details (and have the
RS cache the response for a few seconds/minutes to avoid overloading the
introspection endpoint). That being said, RS knowing the tokens are JWTs
allows them to reject invalid tokens (expired, invalid signature,
unexpected issuer, etc.) without the need to check for revocation at the AS.

It did occur to me that if I make the AT self-contained, then RO-initiated
scope revocation wouldn't take affect until the next time a new AT is
requested using the RT (when the old AT expires), which I was going to set
to 30m to prevent swamping the token endpoint (which would happen if RS's
had to call me to validate the AT every time).

Now that I know about these extra specs, I'm tempted to implement both
(self-contained ATs *and* an introspection endpoint), and see what the
adopters decide to do.

> Either a Web UI, or an API <
https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06> (I'm not
a fan of this draft, and it incidentally violates IETF's BCP190
https://tools.ietf.org/html/bcp190, but I think it's a good source of
inspiration)

What don't you like about it?  And can I mitigate the factors you're
concerned about in my decision-making process without violating the draft
spec?

-ofer

On Tue, Oct 13, 2015 at 5:10 AM, Thomas Broyer <[e-mail]> wrote:

>
>
> On Tue, Oct 13, 2015 at 6:14 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).
>>
>
> Either that (and I'd use JWT then, as already proposed) or have resource
> servers introspect tokens <
> https://tools.ietf.org/html/draft-ietf-oauth-introspection-11> (the
> latter doesn't preclude the former, but the format of the token is then
> just an implementation detail of the AS that the RS doesn't need to know).
> One advantage of requiring introspection is the easy support of revocation
> without having to create a specific API to check whether a token is
> revoked: you just introspect the token and directly know whether the token
> is valid or not, and if it's valid you get its details (and have the RS
> cache the response for a few seconds/minutes to avoid overloading the
> introspection endpoint). That being said, RS knowing the tokens are JWTs
> allows them to reject invalid tokens (expired, invalid signature,
> unexpected issuer, etc.) without the need to check for revocation at the AS.
>
>
>> 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.
>>
>
> Either a Web UI, or an API <
> https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06> (I'm
> not a fan of this draft, and it incidentally violates IETF's BCP190
> https://tools.ietf.org/html/bcp190, but I think it's a good source of
> inspiration)
>