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

Thomas Broyer <t.broyer@gmail.com> Tue, 13 October 2015 09:10 UTC

Return-Path: <t.broyer@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8121A212A for <oauth@ietfa.amsl.com>; Tue, 13 Oct 2015 02:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU-3OGt3yBxT for <oauth@ietfa.amsl.com>; Tue, 13 Oct 2015 02:10:41 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E821A21A6 for <oauth@ietf.org>; Tue, 13 Oct 2015 02:10:40 -0700 (PDT)
Received: by lbbck17 with SMTP id ck17so12122691lbb.1 for <oauth@ietf.org>; Tue, 13 Oct 2015 02:10:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=0V6A4HD5I+psn7mcGfxcTIF+PNbZb+OVYqtI5fxTsXQ=; b=fi1ialQLdpJBovQzDyReTRwE68NRL2UYMajluFsSXeu+7Vd8rNEQb0YssRMknuxz4h P3xfCygR4SLFW6SYWNkVCAQHG5Of1WTpuRMzPW8w5SKNRpYZf0PWot1d0wt1Mbj6YIVN fQNhJPpCb4Et//oyhfaOfFQUpgLMetqJN9ftPab3hNYbYRSVyIrDT/bvgTBLm/vXfde2 vCMYF4//JjVgHjfGWBIjWPgZiztoBO6mj5+O3ok/VSLr5DPgZFUW8As6XBYEVuMzib0J W7dwRe/WWvKGc2iEzg03rVJk4Gnk/5D+EZ+qZqB5qSdJgJtaBjWYGHwpJ9+v59BmdpJs ou7A==
X-Received: by 10.25.16.195 with SMTP id 64mr1873100lfq.62.1444727438778; Tue, 13 Oct 2015 02:10:38 -0700 (PDT)
MIME-Version: 1.0
References: <CABPN19_wYVEvqEU85FDZMYe6k8E8qkL0gGDvFeQMXaaQt+yAbQ@mail.gmail.com>
In-Reply-To: <CABPN19_wYVEvqEU85FDZMYe6k8E8qkL0gGDvFeQMXaaQt+yAbQ@mail.gmail.com>
From: Thomas Broyer <t.broyer@gmail.com>
Date: Tue, 13 Oct 2015 09:10:28 +0000
Message-ID: <CAEayHEM=nHk9TbTFno+7otwNry++cYGcGcGuNM7mi19gE5KjcA@mail.gmail.com>
To: Ofer Nave <odigity@gmail.com>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="001a113fb984c925f10521f8d195"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Mn6P_6rBaTSN2Nfdf9DaGsZMFcc>
Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2015 09:10:42 -0000

On Tue, Oct 13, 2015 at 6:14 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).
>

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)