Subject: [OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant

From: Dick Hardt <[email-masked]>
Date: Thu, 8 Nov 2018 17:42:28 +0700

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

---

From: Omer Levi Hevroni <[email-masked]>
Date: Thu, 8 Nov 2018 21:04:04 +0200

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?

---

From: Dick Hardt <[email-masked]>
Date: Fri, 9 Nov 2018 06:54:42 +0700

More detail on the scenario would help.

On Fri, Nov 9, 2018 at 2:04 AM Omer Levi Hevroni <[email-masked]> wrote:

>> 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: Omer Levi Hevroni <[email-masked]>
Date: Sun, 11 Nov 2018 22:08:11 +0200

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

>>> 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]

---

From: Dick Hardt <[email-masked]>
Date: Mon, 12 Nov 2018 20:19:04 +0700

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.

---

From: Omer Levi Hevroni <[email-masked]>
Date: Tue, 13 Nov 2018 20:06:30 +0200

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.