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<ve7...@ve7jtb.com>さんは書きました: > +1 > JB. > > On Jul 2, 2015, at 1:33 PM, Adam Lewis <adam.le...@motorolasolutions.com > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','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 <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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
