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 list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
