Subject: [OAUTH-WG] Dynamic Client Registration with Native Apps

From: Christian Mainka <[email-masked]>
Date: Tue, 27 Nov 2018 10:44:08 +0100

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

---

From: William Denniss <[email-masked]>
Date: Tue, 27 Nov 2018 12:28:11 -0800

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

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Nov 2018 10:47:27 -0500

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:
> 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=[email-masked]..org 
> <mailto:Christian.Mainka=[email-masked]>> wrote:
>
>     Hi,
>
>     <https://tools.ietf.org/html/rfc8252#section-8.4>
>
>     -- 
>     <http://nds.rub.de/chair/people/cmainka/>
>     @CheariX
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>

---

From: Filip Skokan <[email-masked]>
Date: Wed, 28 Nov 2018 17:03:17 +0100

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

> 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).
>
> Christian.Mainka=[email-masked]..org
> <Christian.Mainka=[email-masked]>> wrote:
>
>> Hi,
>>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Nov 2018 12:03:12 -0500

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:
> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher 
> <gffletch=[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     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
>
>>     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.
>>

---

From: Filip Skokan <[email-masked]>
Date: Wed, 28 Nov 2018 18:09:54 +0100

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

> 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).
>
> 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
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 28 Nov 2018 23:38:44 +0000

It should be noted that “traditional” confidential clients with registered return URLs and server-side secrets may provide a higher degree of confidence in the true identity of the client that doesn’t carry over to confidential native app clients. A native app instance’s registration call is necessarily unauthenticated (for the same reasons that statically registered native app clients are public clients), so the Client Impersonation concerns described in section 8.6 of RFC8252<https://tools.ietf.org/html/rfc8252#section-8.6> still apply.
--
Annabelle Richard Backman
AWS Identity

From: OAuth <[email-masked]> on behalf of Filip Skokan <[email-masked]>
Date: Wednesday, November 28, 2018 at 9:11 AM
To: George Fletcher <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

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

#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=[email-masked]<mailto:[email-masked]>> 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=[email-masked]..org<mailto:Christian.Mainka=[email-masked]>> wrote:
Hi,

Best Regards,
Vladi/Christian

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth<https://www..ietf.org/mailman/listinfo/oauth>

---

From: Christian Mainka <[email-masked]>
Date: Thu, 29 Nov 2018 15:02:46 +0100

Hi,

thanks for pointing this out!
This was exactly what confused us during reading *-* the main threat we
see and which is not addressed is related to the app impersonation attack.
Even PKCE does not help against the app impersonation attack.

So a "Native App + Dynamic Client Registration" can be seen at a
different "confidentiality level" than a "public client", because every
native App can dynamically register itself on the IdP.
The IdP cannot distinguish, for example, an honest native client from an
malicious client starting an app impersonation attack.

We agree that, e.g., a leaked code cannot be redeemed unless you have
the respective client_id/client_secret.

But... we asked ourselfs, in which cases does a code leak?

1) In the front-channel. In this case, it is true that no client
credentials leak and an attacker cannot redeem the code.

2) In the back-channel. But if this channel is insecure, you directly
get client credentials (unless client_secret_jwt is used as pointed out
by George).

So, Dynamic Client Registration only helps if the code leaks alone (as
in 1.), or if it leaks on different levels (e.g. logfiles).

On the opposite site, if Dynamic Registration is available, an attacker
can very easily do an app impersonation attack by registering on the
IdP. To be clear, it is not "impersonation" as in the "one secret per
software" scenario, because different client_id and client_secret is
used, but to the best of my knowledge, the IdP cannot distinguish
between an honest app and an app impersonation client that has simply
registered.

In addition, if the IdP supports the dynamic client registration:
How can the IdP distinguish between confidential and public/native clients?
With respect to the consent page, which must be shown every time for
native apps, this is an important issue, which should be addressed properly.

Best Regards
Vladi/Christian

---

From: Joseph Heenan <[email-masked]>
Date: Thu, 29 Nov 2018 16:18:46 +0000

Hi all,

It’s worth adding that a per-instance dynamic registration of a native client can still imply a higher level of trust than a public client and registration isn’t necessarily unauthenticated. https://tools.ietf.org/html/rfc7591 defines an “initial access token”:

> OAuth 2.0 access token optionally issued by an authorization
> server to a developer or client and used to authorize calls to the
> client registration endpoint.  The type and format of this token
> are likely service specific and are out of scope for this
> specification.  The means by which the authorization server issues
> this token as well as the means by which the registration endpoint
> validates this token are out of scope for this specification.  Use
> of an initial access token is required when the authorization
> server limits the parties that can register a client.

This can be used [for example] to bind a client to a specific user, though the bootstrapping can be a little involved and potentially the bootstrapping still has weaknesses. Use of white box crypto (or other tools like device attestations) can potentially also bring dynamically registered native apps up to a sufficiently trusted level.

Joseph

> On 29 Nov 2018, at 14:02, Christian Mainka <Christian.Mainka=[email-masked]> wrote:
> 
> Hi,
> 
> This was exactly what confused us during reading - the main threat we see and which is not addressed is related to the app impersonation attack.
> So a "Native App + Dynamic Client Registration" can be seen at a different "confidentiality level" than a "public client", because every native App can dynamically register itself on the IdP.
> The IdP cannot distinguish, for example, an honest native client from an malicious client starting an app impersonation attack.
> 
> We agree that, e.g., a leaked code cannot be redeemed unless you have the respective client_id/client_secret.
> 
> 1) In the front-channel. In this case, it is true that no client credentials leak and an attacker cannot redeem the code.
> 
> 2) In the back-channel. But if this channel is insecure, you directly get client credentials (unless client_secret_jwt is used as pointed out by George).
> 
> So, Dynamic Client Registration only helps if the code leaks alone (as in 1.), or if it leaks on different levels (e.g. logfiles).
> 
> On the opposite site, if Dynamic Registration is available, an attacker can very easily do an app impersonation attack by registering on the IdP. To be clear, it is not "impersonation" as in the "one secret per software" scenario, because different client_id and client_secret is used, but to the best of my knowledge, the IdP cannot distinguish between an honest app and an app impersonation client that has simply registered.
> 
> With respect to the consent page, which must be shown every time for native apps, this is an important issue, which should be addressed properly.
> 
> Best Regards
> Vladi/Christian 
> 
>> It should be noted that “traditional” confidential clients with registered return URLs and server-side secrets may provide a higher degree of confidence in the true identity of the client that doesn’t carry over to confidential native app clients. A native app instance’s registration call is necessarily unauthenticated (for the same reasons that statically registered native app clients are public clients), so the Client Impersonation concerns described in section 8.6 of RFC8252<https://tools.ietf.org/html/rfc8252#section-8.6> <https://tools.ietf.org/html/rfc8252#section-8.6> still apply.
>> --
>> From: OAuth <[email-masked]> <mailto:[email-masked]> on behalf of Filip Skokan <[email-masked]> <mailto:[email-masked]>
>> To: George Fletcher <[email-masked]> <mailto:[email-masked]>
>> Cc: oauth <[email-masked]> <mailto:[email-masked]>
>> On Wed, Nov 28, 2018 at 6:03 PM George Fletcher <[email-masked] <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher <gffletch=[email-masked] <mailto:gffletch=[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>> On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <Christian.Mainka=[email-masked]..org <mailto:Christian.Mainka=[email-masked]..org><mailto:Christian.Mainka=[email-masked]> <mailto:Christian.Mainka=[email-masked]>> wrote:
>> Hi,
>> 
>> [1]: https://tools.ietf.org/html/rfc8252#section-8.4 <https://tools.ietf.org/html/rfc8252#section-8.4>
>> 
>> --
>> http://nds.rub.de/chair/people/cmainka/ <http://nds.rub.de/chair/people/cmainka/>
>> @CheariX
>> 
>> 
>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>
>> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>
>> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth><https://www..ietf.org/mailman/listinfo/oauth> <https://www..ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> -- 
> http://nds.rub.de/chair/people/cmainka/ <http://nds.rub.de/chair/people/cmainka/>
> @CheariX

---

From: n-sakimura <[email-masked]>
Date: Thu, 29 Nov 2018 16:48:08 +0000

In the case of dynamic client registration for apps, I suppose the implementations will use other techniques (many of them are proprietary) to test if the app is the one created by themselves or not. Otherwise, it would not improve the situation very much.

Nat

Nat Sakimura / [email-masked] / +81-90-6013-6276

このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。

PLEASE READ :This e-mail is confidential and intended for the named recipient only.
If you are not an intended recipient, please notify the sender and delete this e-mail.

________________________________
差出人: OAuth <[email-masked]> (Joseph Heenan <[email-masked]> の代理)
送信日時: 木曜日, 11月 29, 2018 5:19 午後
宛先: oauth
件名: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

Hi all,

Joseph

On 29 Nov 2018, at 14:02, Christian Mainka <Christian.Mainka=[email-masked]<mailto:Christian.Mainka=[email-masked]>> wrote:

Hi,

Best Regards
Vladi/Christian

It should be noted that “traditional” confidential clients with registered return URLs and server-side secrets may provide a higher degree of confidence in the true identity of the client that doesn’t carry over to confidential native app clients. A native app instance’s registration call is necessarily unauthenticated (for the same reasons that statically registered native app clients are public clients), so the Client Impersonation concerns described in section 8.6 of RFC8252<https://tools..ietf.org/html/rfc8252#section-8.6><https://tools.ietf.org/html/rfc8252#section-8.6> still apply.
--
Annabelle Richard Backman
AWS Identity

From: OAuth <[email-masked]><mailto:[email-masked]> on behalf of Filip Skokan <[email-masked]><mailto:[email-masked]>
Date: Wednesday, November 28, 2018 at 9:11 AM
To: George Fletcher <[email-masked]><mailto:[email-masked]>
Cc: oauth <[email-masked]><mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

Best,
Filip

On Wed, Nov 28, 2018 at 6:03 PM George Fletcher <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>> 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).

Thanks,
George

Best,
Filip

On Wed, Nov 28, 2018 at 4:48 PM George Fletcher <gffletch=[email-masked]<mailto:gffletch=[email-masked]><mailto:[email-masked]><mailto:[email-masked]>> wrote:
In addition, a few additional patterns are enabled...

Thanks,
George

On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <Christian.Mainka=[email-masked]..org<mailto:Christian.Mainka=[email-masked]..org><mailto:Christian.Mainka=[email-masked]><mailto:Christian.Mainka=[email-masked]>> wrote:
Hi,

Best Regards,
Vladi/Christian

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth<https://www..ietf.org/mailman/listinfo/oauth><https://www..ietf.org/mailman/listinfo/oauth>

---

From: William Denniss <[email-masked]>
Date: Thu, 29 Nov 2018 10:49:09 -0800

> Even PKCE does not help against the app impersonation attack.

Claimed "https" scheme URIs (RFC 8252, Sec 7.2) can be used to provide some
identity guarantees (security considerations in Sec 8.6), as the OS will
only open apps that can verify domain ownership to process the redirect.
This is what I would recommend as a starting point if you want assurances
over the app's identity.

A spoofing app can still use a web-view to intercept the response that way,
but in that case they'd also have full access to the session cookie (due to
the use of webview for the sign-in), which is potentially a more valuable
token (i.e. you have bigger issues). It does effectively prevent against
tokens issued form the browser SSO session being intercepted by the wrong
app.

>
> So a "Native App + Dynamic Client Registration" can be seen at a different
> "confidentiality level" than a "public client", because every native App
> can dynamically register itself on the IdP.
> 2) In the back-channel. But if this channel is insecure, you directly get
> client credentials (unless client_secret_jwt is used as pointed out by
> George).
>
> So, Dynamic Client Registration only helps if the code leaks alone (as in
> 1.), or if it leaks on different levels (e.g. logfiles).
>
> can very easily do an app impersonation attack by registering on the IdP.
> To be clear, it is not "impersonation" as in the "one secret per software"
> scenario, because different client_id and client_secret is used, but to the
> best of my knowledge, the IdP cannot distinguish between an honest app and
> an app impersonation client that has simply registered.
>
> From: OAuth <[email-masked]> <[email-masked]> on behalf of Filip Skokan <[email-masked]> <[email-masked]>
> To: George Fletcher <[email-masked]> <[email-masked]>
> Cc: oauth <[email-masked]> <[email-masked]>
> On Wed, Nov 28, 2018 at 6:03 PM George Fletcher <[email-masked]<mailto:[email-masked]> <[email-masked]>> wrote:
> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher <gffletch=[email-masked]<mailto:[email-masked]> <[email-masked]>> wrote:
> On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <Christian.Mainka=[email-masked]..org<mailto:Christian.Mainka=[email-masked]> <Christian.Mainka=[email-masked]>> wrote:
> Hi,
>
> Fax: +49 (0) 234 / 32-14347http://nds.rub.de/chair/people/cmainka/
> @CheariX
>
>
> OAuth mailing [email-masked]<mailto:[email-masked]> <[email-masked]>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> [email-masked]<mailto:[email-masked]> <[email-masked]>
> OAuth mailing [email-masked]<mailto:[email-masked]> <[email-masked]>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> [email-masked]<mailto:[email-masked]> <[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth<https://www..ietf.org/mailman/listinfo/oauth> <https://www..ietf.org/mailman/listinfo/oauth>
>
>
> Fax: +49 (0) 234 / 32-14347http://nds.rub.de/chair/people/cmainka/
> @CheariX
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 30 Nov 2018 00:17:36 +0000

> Claimed "https" scheme URIs (RFC 8252, Sec 7.2) can be used to provide some identity guarantees…

Yes, provided that the AS can verify that the claimed URI is a valid URI for the identity being asserted by the client. And this identity guarantee would apply to an public native app client just as well as one that has established a client secret via dynamic client registration.

Section 2.3 of RFC6749<https://tools.ietf.org/html/rfc6749#section-2.3> is relevant here:

The authorization server MAY establish a client authentication method
with public clients.  However, the authorization server MUST NOT rely
on public client authentication for the purpose of identifying the
client.

From: OAuth <[email-masked]> on behalf of William Denniss <wdenniss=[email-masked]>
Date: Thursday, November 29, 2018 at 10:49 AM
To: Christian Mainka <Christian.Mainka=[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

On Thu, Nov 29, 2018 at 6:03 AM Christian Mainka <Christian.Mainka=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Claimed "https" scheme URIs (RFC 8252, Sec 7.2) can be used to provide some identity guarantees (security considerations in Sec 8.6), as the OS will only open apps that can verify domain ownership to process the redirect. This is what I would recommend as a starting point if you want assurances over the app's identity.

A spoofing app can still use a web-view to intercept the response that way, but in that case they'd also have full access to the session cookie (due to the use of webview for the sign-in), which is potentially a more valuable token (i.e. you have bigger issues). It does effectively prevent against tokens issued form the browser SSO session being intercepted by the wrong app.

Best Regards
Vladi/Christian

It should be noted that “traditional” confidential clients with registered return URLs and server-side secrets may provide a higher degree of confidence in the true identity of the client that doesn’t carry over to confidential native app clients. A native app instance’s registration call is necessarily unauthenticated (for the same reasons that statically registered native app clients are public clients), so the Client Impersonation concerns described in section 8.6 of RFC8252<https://tools.ietf.org/html/rfc8252#section-8.6><https://tools.ietf.org/html/rfc8252#section-8.6> still apply.

--

AWS Identity

Best,

Filip

Thanks,

George

Hi George,

Best,

Filip

Thanks,

George

Hi,

Confidential Client?

Native Apps?

Best Regards,

Vladi/Christian

--

D-44801 Bochum, Germany

@CheariX

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

--

D-44801 Bochum, Germany

@CheariX

---

From: William Denniss <[email-masked]>
Date: Thu, 29 Nov 2018 23:22:47 -0800

On Thu, Nov 29, 2018 at 4:17 PM, Richard Backman, Annabelle <
richanna=[email-masked]> wrote:

> Yes, provided that the AS can verify that the claimed URI is a valid URI
> for the identity being asserted by the client. And this identity guarantee
> would apply to an public native app client just as well as one that has
> established a client secret via dynamic client registration.
>

I agree.

>
>
> Section 2.3 of RFC6749 <https://tools.ietf.org/html/rfc6749#section-2.3>
> is relevant here:
>
>
>
> *From: *OAuth <[email-masked]> on behalf of William Denniss
> <wdenniss=[email-masked]>
> *Date: *Thursday, November 29, 2018 at 10:49 AM
> *To: *Christian Mainka <Christian.Mainka=[email-masked]>
>
> *Cc: *oauth <[email-masked]>
> *Subject: *Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
>
>
>
>
>
> Claimed "https" scheme URIs (RFC 8252, Sec 7.2) can be used to provide
> some identity guarantees (security considerations in Sec 8.6), as the OS
> will only open apps that can verify domain ownership to process the
> redirect. This is what I would recommend as a starting point if you want
> assurances over the app's identity.
>
>
>
> A spoofing app can still use a web-view to intercept the response that
> way, but in that case they'd also have full access to the session cookie
> (due to the use of webview for the sign-in), which is potentially a more
> valuable token (i.e. you have bigger issues). It does effectively prevent
> against tokens issued form the browser SSO session being intercepted by the
> wrong app.
>
>
>
>
>
>
> Ruhr-University Bochum, Germany <https://maps.google.com/?q=Bochum,+Germany+%0D%0A+%0D%0A+Universit%C3%A4tsstr.+150&entry=gmail&source=g>
>
>
>
> Universitätsstr. 150 <https://maps.google.com/?q=Bochum,+Germany+%0D%0A+%0D%0A+Universit%C3%A4tsstr.+150&entry=gmail&source=g>, ID 2/463
>
> D-44801 Bochum, Germany
>
>
>
> Ruhr-University Bochum, Germany <https://maps.google.com/?q=Bochum,+Germany+%0D%0A+%0D%0A+Universit%C3%A4tsstr.+150&entry=gmail&source=g>
>
>
>
> Universitätsstr. 150 <https://maps.google.com/?q=Bochum,+Germany+%0D%0A+%0D%0A+Universit%C3%A4tsstr.+150&entry=gmail&source=g>, ID 2/463
>
> D-44801 Bochum, Germany
>
>
>