Apologies, I missed the *issued* in "issued a shared secret", just reading "shared secret" alone is the exact opposite of a per-instance secret. The rest is clear and as you say it brings the benefit of the secret never being sent over the wire (except during the initial registration via TLS).
Best, *Filip* On Wed, Nov 28, 2018 at 6:03 PM George Fletcher <gffle...@aol.com> wrote: > 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> 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 >> <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 >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
