IETF Logo Mail Archive

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

Jim Manico <jim@manicode.com> Tue, 13 October 2015 04:36 UTC

Return-Path: <jim@manicode.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 0E7861B3749 for <oauth@ietfa.amsl.com>; Mon, 12 Oct 2015 21:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Oo-SZMLstxtc for <oauth@ietfa.amsl.com>; Mon, 12 Oct 2015 21:36:23 -0700 (PDT)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 2D29D1AD324 for <oauth@ietf.org>; Mon, 12 Oct 2015 21:36:23 -0700 (PDT)
Received: by wicge5 with SMTP id ge5so40253091wic.0 for <oauth@ietf.org>; Mon, 12 Oct 2015 21:36:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=S+567zt0EWfhHj3Lu4u7Gw4BDNIOsGbi1A4wf4rUoeo=; b=L8EXvHUvbVHW9bkNAO4YXIso1wkll//9KMfLu+i3outzETPZl5hkoGADpUIKHDm7q2 gQWq9QEz+0/Sr2vIEj5bnTvxVTM9Mfkdq/dJEsE6TRzCrPeCwjVSvddvpV5tdsZbxC25 JDZf4dS9TQyKvL2mkDEjqh5XqS7giDl2vdTICzA3OgDIlEw00/6HvdHzhEBbqUHdsYb9 d1SXe/aEIdVKpbLZG2AvDA40saM7ejqJm8wzW4HPatdfcHEPW0ziQ4jO/GcgtHJby6Vl aCdZcL/w7YtEB/RqbgXBXQTLbs3P8rq8ijIw5UNskCgVYpkR8cUsVtOJUBiPl48ynQ0H eJmw==
X-Gm-Message-State: ALoCoQnbxeXd5RdWafrLvhQpR0Zo73vPpTf77pCQ7bQoGIaWiMTYNpLQVJB81k+LGQWYNK22B7gG
X-Received: by 10.180.189.102 with SMTP id gh6mr16642942wic.95.1444710981727; Mon, 12 Oct 2015 21:36:21 -0700 (PDT)
Received: from [192.168.2.17] (ip5456cfcc.speed.planet.nl. [84.86.207.204]) by smtp.gmail.com with ESMTPSA id qh12sm6841704wic.20.2015.10.12.21.36.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Oct 2015 21:36:20 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Jim Manico <jim@manicode.com>
X-Mailer: iPhone Mail (13A452)
In-Reply-To: <CABPN19_wYVEvqEU85FDZMYe6k8E8qkL0gGDvFeQMXaaQt+yAbQ@mail.gmail.com>
Date: Tue, 13 Oct 2015 06:36:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <751A2989-38CD-4360-A691-980AA8DE58A8@manicode.com>
References: <CABPN19_wYVEvqEU85FDZMYe6k8E8qkL0gGDvFeQMXaaQt+yAbQ@mail.gmail.com>
To: Ofer Nave <odigity@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Rr-AE2gExtfnZnV3oLRT_ijc5HI>
Cc: oauth@ietf.org
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 04:36:25 -0000

This seems like a reasonable approach. Isn't the whole idea of the auth server/resource server separation in OAuth 2.0 so that one auth server can govern multiple resource servers?

--
Jim Manico
@Manicode

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

v2.23.0 | Report a Bug | By Email