+1 JB. > On Jul 2, 2015, at 1:33 PM, Adam Lewis <adam.le...@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_...@symantec.com > <mailto: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 <mailto:lisa_...@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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > 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
