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

From: Lisa Li1 <[email-masked]>
Date: Mon, 29 Jun 2015 19:18:00 -0700

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
[email-masked]

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.

---

From: Bill Mills <[email-masked]>
Date: Thu, 2 Jul 2015 16:28:10 +0000 (UTC)

Using Bearer tokens with refresh tokens is a valid use case for server-to-server and has the same nice properties that is does for users, in that it applies a single control point for revoking access.  Using Bearer tokens has very different security properties than OAuth 1.0a and you should carefully consider this.  Look at the proof-of-posession work rather than simple Bearer tokens. 

     On Thursday, July 2, 2015 9:10 AM, Lisa Li1 <[email-masked]> wrote:

 <!--#yiv0512297667 _filtered #yiv0512297667 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv0512297667 {font-family:SimSun;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv0512297667 {font-family:SimSun;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv0512297667 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0512297667 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #yiv0512297667 {panose-1:2 1 6 0 3 1 1 1 1 1;}#yiv0512297667 #yiv0512297667 p.yiv0512297667MsoNormal, #yiv0512297667 li.yiv0512297667MsoNormal, #yiv0512297667 div.yiv0512297667MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", "sans-serif";}#yiv0512297667 a:link, #yiv0512297667 span.yiv0512297667MsoHyperlink {color:blue;text-decoration:underline;}#yiv0512297667 a:visited, #yiv0512297667 span.yiv0512297667MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv0512297667 p.yiv0512297667MsoAcetate, #yiv0512297667 li.yiv0512297667MsoAcetate, #yiv0512297667 div.yiv0512297667MsoAcetate {margin:0in;margin-bottom:.0001pt;font-size:8.0pt;font-family:"Tahoma", "sans-serif";}#yiv0512297667 span.yiv0512297667EmailStyle17 {font-family:"Calibri", "sans-serif";color:windowtext;}#yiv0512297667 span.yiv0512297667BalloonTextChar {font-family:"Tahoma", "sans-serif";}#yiv0512297667 .yiv0512297667MsoChpDefault {font-family:"Calibri", "sans-serif";} _filtered #yiv0512297667 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0512297667 div.yiv0512297667WordSection1 {}-->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 LiPrincipal Software EngineerSymantec Corporation  Office: (010) 6272 5127  /  Mobile: 189 1057 [email-masked]      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
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Adam Lewis <[email-masked]>
Date: Thu, 2 Jul 2015 11:33:33 -0500

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 <[email-masked]> wrote:

> 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*
>
> [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.
>
>
>

---

From: John Bradley <[email-masked]>
Date: Thu, 2 Jul 2015 22:19:03 -0300

+1 
JB.

> On Jul 2, 2015, at 1:33 PM, Adam Lewis <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi All
> 
>  
> 
> This is Lisa.
> 
> 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
> 
> [email-masked] <mailto:[email-masked]>
>  
> 
> 
>  
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 6 Jul 2015 12:19:49 +0900

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<[email-masked]>さんは書きました:

> +1
> JB.
>
> On Jul 2, 2015, at 1:33 PM, Adam Lewis <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> Hi Lisa,
>
> 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).
> 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
> On Mon, Jun 29, 2015 at 9:18 PM, Lisa Li1 <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> Hi All
>>
>>
>>
>> This is Lisa.
>>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>>
>>
>>
>>
>>
>>
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

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