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_...@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_...@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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
