Ok, thanks for the clarification. Your point about a user with multiple devices is correct - but it is by design. The goal of this protocol is to allow device authentication - there is no information about the user. Therefore, there is also no way to associate devices to a user. It creates challenges, but it also opens new opportunities - for cases when there is no need in user entity, only strong authentication solution. Could you elaborate more about why do you think that "the private key protections you have in place are a net positive"?
Finally, yes, it's just a small change to JWT client assertion, that make it more usable on physical devices. On Mon, Nov 12, 2018 at 3:19 PM Dick Hardt <dick.ha...@gmail.com> wrote: > I understand better, thanks! > > From an OAuth perspective, this is a client credentials grant. You have > added some other checks that may or may not help the security profile, but > at the core, you have a private key on the device that is the primary > credential, and is device oriented. > > FWIW: there are a number of usability challenges with your approach. The > user can't use more than one device. If they change devices, they lose all > their data. Also, IMHO, I don't think the private key protections you have > in place are a net positive. > > > > > On Mon, Nov 12, 2018 at 3:08 AM Omer Levi Hevroni <ome...@gmail.com> > wrote: > >> Ok, let me try. >> >> At the company where I work, we have an app that is used by our users. We >> want to have a way to authenticate the requests from the application, >> without requiring the user to perform any interactive login flow. I >> described it more in-depth in the blog post - >> https://blog.solutotlv.com/userless-mobile-authentication/ >> >> Does this help? >> >> Also, thank you for your time and feedback. I appreciate it! >> >> On Fri, Nov 9, 2018 at 1:54 AM Dick Hardt <dick.ha...@gmail.com> wrote: >> >>> More detail on the scenario would help. >>> >>> On Fri, Nov 9, 2018 at 2:04 AM Omer Levi Hevroni <ome...@gmail.com> >>> wrote: >>> >>>> Yes, that is correct. >>>> I'm sorry the confusion, I think this confusion is built into >>>> oauth framework itself. >>>> You understood well the scenario - I have an application running on an >>>> untrusted device in an untrusted network. I looked for a way to >>>> authenticate the requests from the device to AS. >>>> Does it make more sense now? >>>> >>>> On Thu, Nov 8, 2018 at 12:42 PM Dick Hardt <dick.ha...@gmail.com> >>>> wrote: >>>> >>>>> Omar >>>>> >>>>> As promised, I have reviewed the ID[1] you posted. I'm confused in the >>>>> Motivation by the references to authentication, as OAuth is about >>>>> authorization. >>>>> >>>>> Perhaps you can post to the list the use case you are trying to solve >>>>> for? I can infer aspects, but don't fully understand it. >>>>> >>>>> From what I can understand though, there is software running in a >>>>> trusted device that would like to get an access token, and an OTP is part >>>>> of how the device is authenticating to the AS. This seems like a 2 legged >>>>> OAuth flow as there is no user involved directly, and it seems you have a >>>>> means for the client to authenticate to the AS using an OTP. Am I guessing >>>>> correctly? >>>>> >>>>> /Dick >>>>> >>>>> [1] >>>>> https://datatracker.ietf.org/doc/draft-hevroni-oauth-seamless-flow/?include_text=1 >>>>> >>>>> >>>>>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
