It's "confidential" in that the shared secret is unique to that app
instance registration (as Dennis described in his response). If an
attacker gets my phone and compromises the data stored on my device,
they only get the secret for my device. This is no different than a
server side client having their client secret compromised through an
attack (and in some ways is better because it's instance specific).
The main point I was trying to make, is that the 'client_secret_jwt'
method allows the client to never send the shared secret across the wire
as is created in the default OAuth2 HTTP Basic Authentication method.
Thanks,
George
On 11/28/18 11:03 AM, Filip Skokan wrote:
Hi George,
#2 doesn't seem confidential, it's still a secret shared amongst
installations and anyone reverse engineering the apk, extracting the
secret, can form the client_secret_jwt client_assertion with it just fine.
Best,
Filip
On Wed, Nov 28, 2018 at 4:48 PM George Fletcher
<gffletch=40aol....@dmarc.ietf.org <mailto:40aol....@dmarc.ietf.org>>
wrote:
In addition, a few additional patterns are enabled...
1. The native app can generate a public/private key pair and then
use private_secret_jwt as the client credential validation method
via the client credentials flow (defined in OpenID Connect).
2. Maybe more simply, if the native app is issued a shared secret,
the app can use client_secret_jwt method for client authentication
which ensures the shared secret never leaves the device. (Again
defined in the OpenID Connect spec).
3. Once the native app instance has credentials, they can be used
for additional securing of app API transactions in addition to
just the OAuth2/OpenID Connect flows.
Thanks,
George
On 11/27/18 3:28 PM, William Denniss wrote:
If the secret is dynamically provisioned then you have a
confidential client. Anyone reverse engineering their own
installation of the native app would only extract their own
client's credentials, as opposed to the shared secret of all
installations. Having a confidential client means that requests
to the token endpoint (code, refresh) are client authenticated,
so PKCE wouldn't be needed.
On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka
<Christian.Mainka=40rub...@dmarc.ietf..org
<mailto:Christian.Mainka=40rub...@dmarc.ietf.org>> wrote:
Hi,
we just stumbled upon this [1] statement:
"Except when using a mechanism like Dynamic Client Registration
[RFC7591] to provision per-instance secrets, native apps are
classified as public clients ..."
What does this mean for us? Native App + Dynamic Client
Registration =
Confidential Client?
Which threats are covered if Dynamic Client Registration is
used on
Native Apps?
Best Regards,
Vladi/Christian
[1]: https://tools.ietf.org/html/rfc8252#section-8.4
--
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security
Chair for Network and Data Security
Ruhr-University Bochum, Germany
Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany
Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
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
