[OAUTH-WG] Auth Server / Resource Server Coordination

Ofer Nave <odigity@gmail.com> Tue, 13 October 2015 04:13 UTC

Return-Path: <odigity@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 AB0DD1B3727 for <oauth@ietfa.amsl.com>; Mon, 12 Oct 2015 21:13:59 -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 MEyeF1eYssic for <oauth@ietfa.amsl.com>; Mon, 12 Oct 2015 21:13:58 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 373321B32C3 for <oauth@ietf.org>; Mon, 12 Oct 2015 21:13:58 -0700 (PDT)
Received: by wieq12 with SMTP id q12so11624900wie.1 for <oauth@ietf.org>; Mon, 12 Oct 2015 21:13:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RFfXncTRmUOKMS6DJOC4GFh9LFmaK0Ic28siTqpbomE=; b=G5ruW4EZar5EWzgAm6sBlPqtlg5NJxetzkKUomhN/VJ0T2DNmd77XU0hgidjucYQVt 4qv9tDUgrK641x7AkNmLAvYDn4HdBpkTI+rV1OV15h9JBhM1FFSx99tPnr9hUWWenhkJ v0L1A9bKKuHliZOuWNTWm6LQGdEBwqp1zuhYLq5CdZFLI0rTg/hckYPu7l9k7VFdyriZ TnamqAkcvLiHsrRPy76acVo/3fPJvF2E0SRJvmFvrtE9ifEUt3VVrgmFi/gxfwWB3+NE EqxbarriJfZleTOg7565Mm/k23nFP8iIYNJ2V0H6u1A+OA8bumkzltAKeNS4Fj4Lt0sD Rj5w==
MIME-Version: 1.0
X-Received: by 10.194.133.105 with SMTP id pb9mr25612366wjb.158.1444709636686; Mon, 12 Oct 2015 21:13:56 -0700 (PDT)
Received: by 10.27.125.70 with HTTP; Mon, 12 Oct 2015 21:13:56 -0700 (PDT)
Date: Tue, 13 Oct 2015 00:13:56 -0400
Message-ID: <CABPN19_wYVEvqEU85FDZMYe6k8E8qkL0gGDvFeQMXaaQt+yAbQ@mail.gmail.com>
From: Ofer Nave <odigity@gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="089e01227ee8b2cdd00521f4ac27"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/KvfbvacRrdmi8FTL_6Q1ZBoE19c>
Subject: [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 04:13:59 -0000

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