[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
- [OAUTH-WG] Auth Server / Resource Server Coordina… Ofer Nave
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Bill Mills
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Jim Manico
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Ofer Nave
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Ofer Nave
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Justin Richer
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Thomas Broyer
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Ofer Nave
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Ofer Nave
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Ofer Nave
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Ofer Nave
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Bill Mills
- Re: [OAUTH-WG] Auth Server / Resource Server Coor… Eve Maler
- [OAUTH-WG] Is authorization challenge always need… Sergey Beryozkin
- Re: [OAUTH-WG] Is authorization challenge always … Justin Richer
- Re: [OAUTH-WG] Is authorization challenge always … Sergey Beryozkin