Re: [OAUTH-WG] Question about usage of OAuth between servers

Adam Lewis <adam.lewis@motorolasolutions.com> Thu, 02 July 2015 16:34 UTC

Return-Path: <adam.lewis@motorolasolutions.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 E6D671AD1A3 for <oauth@ietfa.amsl.com>; Thu, 2 Jul 2015 09:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.944
X-Spam-Level:
X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 VftTj1cCuVjY for <oauth@ietfa.amsl.com>; Thu, 2 Jul 2015 09:34:13 -0700 (PDT)
Received: from mx0a-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20BA41AD2D9 for <oauth@ietf.org>; Thu, 2 Jul 2015 09:33:55 -0700 (PDT)
Received: from pps.filterd (m0074411.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.15.0.59/8.14.7) with SMTP id t62GUFla008303 for <oauth@ietf.org>; Thu, 2 Jul 2015 11:33:54 -0500
Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by mx0a-0019e102.pphosted.com with ESMTP id 1vd8npg133-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <oauth@ietf.org>; Thu, 02 Jul 2015 11:33:54 -0500
Received: by ykdr198 with SMTP id r198so72995515ykd.3 for <oauth@ietf.org>; Thu, 02 Jul 2015 09:33:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jXdPYVNxZHH2lcLvP22HlhUrd1M6tpxy0QFzvvUBGug=; b=BJhDDVlEr5Cf1pXXZpTV9EKc1MgFB1Z1HmGbXaMBg7jnodPdzpxF+5ei8086ZWCZ0I 9C4rpHs8ZfDmJ9QgE3yMd730DHDovvCROP6zePuD+bGB8SpzTrc5AB2eQKEp++O/IBmE Im6ckJi1ifewve7I8/V9ndaaCRSE99CC5ba5jQwiLtNXfZCY46xgBMgI2h3PhyrVu693 /Mh9dquyvSiR8JRM9yNKUTLCskdg90ZzLvsyPYdnbC0iwzvQtXVjJwTgzC7tTcT8i3Ax p2wI5Vowzm7SRUGV7J53mEnAZfbQc1rGsIxxtJaw3yzSA76LZNFKMLuPrcXmFv9OWplE eo2Q==
X-Gm-Message-State: ALoCoQlrlwCA2a4ZXbZ4tjTYqr3G5PIOYmKmdz7uuz9b08zVki5z2KgdLI/zDU+nfPxQBsvqBWkn4x8Y9wN8m1VYnwqltxCrPE1m/ljq2m3u6IlP4lh6Gfp9JTUvz4qZox/u3HgpfGJg
X-Received: by 10.170.187.134 with SMTP id d128mr39534846yke.103.1435854833470; Thu, 02 Jul 2015 09:33:53 -0700 (PDT)
X-Received: by 10.170.187.134 with SMTP id d128mr39534831yke.103.1435854833286; Thu, 02 Jul 2015 09:33:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.73.70 with HTTP; Thu, 2 Jul 2015 09:33:33 -0700 (PDT)
In-Reply-To: <47E83806AE926749BB17D1020685E6901903F0CC5F@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM>
References: <47E83806AE926749BB17D1020685E6901903F0CC5F@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM>
From: Adam Lewis <adam.lewis@motorolasolutions.com>
Date: Thu, 2 Jul 2015 11:33:33 -0500
Message-ID: <CAOahYUzDhygTdan6cH3iu5vCZ97oWOmULoRcgtGdtCobHHYg8A@mail.gmail.com>
To: Lisa Li1 <Lisa_Li1@symantec.com>
Content-Type: multipart/related; boundary=001a1139cf2249d81c0519e7015a
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=1 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507020257
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/WnaoD4A4XibV7la29UPH4GK1I28>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Question about usage of OAuth between servers
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: Thu, 02 Jul 2015 16:34:16 -0000

Hi Lisa,

Form the perspective of OAuth, there is ALWAYS a client (even if it is
running on a server).  Of your two servers, one is exposing an API (so this
will be your RS), and the other server is a client of that API, so that
will be your Client.  So it is still a client-server communication.

So it's a question then if whether or not the server (acting as an API
client) is accessing the other server's API on it's own behalf or on behalf
of an end user, and if acting on behalf of an end user, then how does the
end user interact with the server (acting as the API client)?

If the server acting as an API client is acting on its own behalf, then you
want the client credential grant type (or possible a SAML or JWT assertion).
If the server acting as an API client is acting on behalf of an end user
and the end user is coming in through a browser, then you want the
authorization code grant type.
If the server acting as an API client is acting on behalf of an end user
and the end user directly signs onto the server, then you might be stuck
using the RO password grant type.

authorization code and RO grant types give you a refresh token that you can
use to refresh the access token.  In the case of client credentials, the
client stores a long term PSK or has a public private key pair used to
request access tokens, so it will directly communicate with the token
endpoint using those to get new access tokens.

Does that make sense?
adam

On Mon, Jun 29, 2015 at 9:18 PM, Lisa Li1 <Lisa_Li1@symantec.com> wrote:

> Hi All
>
>
>
> This is Lisa.
>
> Our project is adopting OAuth 2 as authentication specification.
>
> For the client-server communication, OAuth token works fine. But we have
> some cases of server to server communication, usually it will be multiple
> tasks running in parallel or sequence or even in multiple threads. In this
> case, we are not sure we should reuse the access token grant by end user or
> create another token? Moreover, if token is expired in 30 min, we are able
> to do refresh but may meet some issue on the token consistency between each
> task, thus it might be refreshed again and again…
>
>
>
> But with OAuth 1.0, since it will not expired and we don’t have to do
> refresh, it will work fine.
>
>
>
> So for OAuth 2.0, what’s your consideration for server to server
> communication scenario? Or do you have any suggestion here?
>
>
>
> Thanks.
>
>
>
>
>
> *Lisa Li*
>
> Principal Software Engineer
>
> Symantec Corporation
>
>
>
> Office: (010) 6272 5127  /  Mobile: 189 1057 2219
>
> Lisa_Li1@symantec.com
>
>
>
> [image: Mac Pro 7
> HD:Users:megumi:Desktop:VERITAS_IDENTITY:ASSETS_DELIVERED:VERITAS_ESIG_RED_w_TM.png]
>
>
>
>
>
> This message (including any attachments) is intended only for the use of
> the individual or entity to which it is addressed and may contain
> information that is non-public, proprietary, privileged, confidential, and
> exempt from disclosure under applicable law or may constitute as attorney
> work product. If you are not the intended recipient, you are hereby
> notified that any use, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, notify us immediately by telephone and (i) destroy
> this message if a facsimile or (ii) delete this message immediately if this
> is an electronic communication.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>