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

Nat Sakimura <sakimura@gmail.com> Mon, 06 July 2015 03:19 UTC

Return-Path: <sakimura@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 B4CF71B2A61 for <oauth@ietfa.amsl.com>; Sun, 5 Jul 2015 20:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 l-WiXedvgJHi for <oauth@ietfa.amsl.com>; Sun, 5 Jul 2015 20:19:50 -0700 (PDT)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 0E5E61B2A5D for <oauth@ietf.org>; Sun, 5 Jul 2015 20:19:50 -0700 (PDT)
Received: by obbnt2 with SMTP id nt2so17844521obb.0 for <oauth@ietf.org>; Sun, 05 Jul 2015 20:19:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/TJQ5/xrwTzdL4/Fze+EmQEdw2oQRqxrcZmHCU13hrQ=; b=qq8CHOyfaOPPGziHZoo8X0zoI9EicjtwaRhvRcopzpA7hqqrHt2N9sjv0aCd54UKQB zW17WNFNO6JiBmudPJ2C/LKO4shAw7s/MrWu3rP9jD0ul+Id9yeAtz6vygehE3DnR4le y1L+pOwdCvdXisJ0zR2zuyvqwqOIRFqTCcV71cEg/2h/S+56IDoND+juYKgk8hH+uSmU uqSYVwi05Y411D9wMbpKJaUwiidzu5k0kA51R5wBEeYdoTVE/gAgGEOAc8/kvndMBY1E W2P/g2+pJrG+ZjKS+TD6YLc9I9prUjODeucVBZ63wpqcoaQc/Dh+lgtMiia8i7htwZsT y85w==
MIME-Version: 1.0
X-Received: by 10.202.240.215 with SMTP id o206mr43147195oih.94.1436152789571; Sun, 05 Jul 2015 20:19:49 -0700 (PDT)
Received: by 10.182.96.66 with HTTP; Sun, 5 Jul 2015 20:19:49 -0700 (PDT)
In-Reply-To: <2A451AC4-6414-4318-B188-C944E205C7E1@ve7jtb.com>
References: <47E83806AE926749BB17D1020685E6901903F0CC5F@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM> <CAOahYUzDhygTdan6cH3iu5vCZ97oWOmULoRcgtGdtCobHHYg8A@mail.gmail.com> <2A451AC4-6414-4318-B188-C944E205C7E1@ve7jtb.com>
Date: Mon, 6 Jul 2015 12:19:49 +0900
Message-ID: <CABzCy2BbjcMvqN98cpT0YAOVLRiy1BZkhqSmDxDZcgrMFZPHOQ@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=94eb2c09204edd9eac051a2c60a5
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/cSenfHaGRbBLhB9xiLc7DZbYStE>
Cc: Lisa Li1 <Lisa_Li1@symantec.com>, "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: Mon, 06 Jul 2015 03:19:52 -0000

Hi Lisa,

So, what are you trying to Authenticate?
OAuth by itself does not authenticate an end-user.
Or are you just concerned with authorization which is embodied in access
and refresh tokens?

Also, whether you should go to HoK or stay with bearer really depends on
the risk that arises from a compromise.

Nat

2015年7月3日金曜日、John Bradley<ve7jtb@ve7jtb.com>さんは書きましたは書きました:

> +1
> JB.
>
> On Jul 2, 2015, at 1:33 PM, Adam Lewis <adam.lewis@motorolasolutions.com
> <javascript:_e(%7B%7D,'cvml','adam.lewis@motorolasolutions.com');>> wrote:
>
> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','Lisa_Li1@symantec.com');>
>>
>>
>>
>> <image002.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 <javascript:_e(%7B%7D,'cvml','OAuth@ietf.org');>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <javascript:_e(%7B%7D,'cvml','OAuth@ietf.org');>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en