Subject: [OAUTH-WG] Implicit clients in Dynamic Registration

From: Phil Hunt <[email-masked]>
Date: Fri, 24 May 2013 11:35:07 -0700

I wanted to bring out a quick discussion to ask the question if it makes sense to support implicit clients in dynamic registration.

By definition, implicit clients are unauthenticated. Therefore the only purpose to register an implicit client is to obtain a client_id with a particular AS instance.

A few issues to consider:
* Implicit clients typically run in browsers (javascript). Do we really want each occurrence of a browser running a client to register?
   --> This could mean even the same browser running implicit flow repeat times, would register repeatedly.
   --> If registration occurs per occurrence, what is the value?

* What use cases typically occur for deployment against different AS and Resource API instances?
   --> Eg. I can see a javascript component of a web site that uses a corresponding resource API.  So it may be possible that the javascript and the resource API are running in the same domain.   In this case, the javascript code, though written as part of a shared library/distribution, is still bound to a configured AS deployment.  Is it really dynamic? If this is the case, wouldn't an OOB registration that updates the client_id in the deployment be better suited?
   --> Are there any examples of javascript clients that need to connect to one or more AS servers on a truly dynamic basis?

* Is there a DOS attack possible (even unintentionally) because implicit clients will start to register frequently creating huge numbers of client_ids that cause spin-off provisioning issues depending on how AS registration, token, and policy systems are implemented?

Apparently OIDC and UMA had these profiles supported before, but I'm really trying to understand why implicit clients should have dynamic registration support.  Would appreciate any discussion on this.  At minimum, there are probably some security considerations we need to think through and document.

Thanks for your comments,

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Josh Mandel <[email-masked]>
Date: Fri, 24 May 2013 13:21:46 -0700

I think this discussion mixes two separable questions:

1. Should dyn-reg support client-side browser-based apps (which need
 client_ids for each AS they talk to, even if they only talk briefly and
then throw the credentials away)?

2. Which authorization flows are available to clients?

I have examples of client-side browser-based apps that fetch blood pressure
values from the BlueButton+ API, and do some calculations / visualizations.
 These apps need to run against any of a large collection of data holders
(all of whom implement the same API endpoints), and may learn about new
data holders in realtime from an end-user.

If we believe this kind of app is a valid use case for dyn reg (Q. #1),
then whether it uses Implicit or Code flow (Q. #2) has no bearing on the
overall set of concerns you raise. (Unintentional DOS, for example, is no
less an issue with the code flow, for browser-based apps that need a
throwaway client_id for brief interactions.) And from an app developer's
perspective, Implicit flow is simpler and better captures the semantics of
a public client.

Thoughts?

  -Josh
On May 24, 2013 11:35 AM, "Phil Hunt" <[email-masked]> wrote:

> I wanted to bring out a quick discussion to ask the question if it makes
> sense to support implicit clients in dynamic registration.
>
> By definition, implicit clients are unauthenticated. Therefore the only
> purpose to register an implicit client is to obtain a client_id with a
> particular AS instance.
>
> * Implicit clients typically run in browsers (javascript). Do we really
> want each occurrence of a browser running a client to register?
>    --> Eg. I can see a javascript component of a web site that uses a
> corresponding resource API.  So it may be possible that the javascript and
> the resource API are running in the same domain.   In this case, the
> javascript code, though written as part of a shared library/distribution,
> is still bound to a configured AS deployment.  Is it really dynamic? If
> this is the case, wouldn't an OOB registration that updates the client_id
> in the deployment be better suited?
>    --> Are there any examples of javascript clients that need to connect
> to one or more AS servers on a truly dynamic basis?
>
> * Is there a DOS attack possible (even unintentionally) because implicit
> clients will start to register frequently creating huge numbers of
> client_ids that cause spin-off provisioning issues depending on how AS
> registration, token, and policy systems are implemented?
>
> Apparently OIDC and UMA had these profiles supported before, but I'm
> really trying to understand why implicit clients should have dynamic
> registration support.  Would appreciate any discussion on this.  At
> minimum, there are probably some security considerations we need to think
> through and document.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 24 May 2013 20:36:28 +0000

I agree with Josh, and I believe that this kind of application should definitely be supported. One of my goals with the Dynamic Registration draft was to make it so that it could be used for all the various flavors of OAuth that people are using today. But that said, I'm not at all against giving guidance to how and where to use it with these various flavors.

And regarding the DOS, one thing that the RESTful API here gives us is a means for well-behaved clients to clean up after themselves, where possible. Say the Blood Pressure Grapher is done with its session, it can call the Client Configuration Endpoint and DELETE itself, helping mitigate a flood of one-time-use client_ids. Doesn't necessarily help the case where the clients can't (or won't) clean up after themselves, or with a deliberate DOS, but there's a security consideration about throttling the registration endpoint already. Perhaps we should have something about "if the client_id hasn't been used in any grants in some amount of time, the AS should throw it away". But how long that is and at what level of client_id overpopulation the AS starts to care is way outside of the spec.

 -- Justin

On May 24, 2013, at 4:21 PM, Josh Mandel <[email-masked]<mailto:[email-masked]>>
 wrote:

1. Should dyn-reg support client-side browser-based apps (which need  client_ids for each AS they talk to, even if they only talk briefly and then throw the credentials away)?

I have examples of client-side browser-based apps that fetch blood pressure values from the BlueButton+ API, and do some calculations / visualizations.  These apps need to run against any of a large collection of data holders (all of whom implement the same API endpoints), and may learn about new data holders in realtime from an end-user.

If we believe this kind of app is a valid use case for dyn reg (Q. #1), then whether it uses Implicit or Code flow (Q. #2) has no bearing on the overall set of concerns you raise. (Unintentional DOS, for example, is no less an issue with the code flow, for browser-based apps that need a throwaway client_id for brief interactions.) And from an app developer's perspective, Implicit flow is simpler and better captures the semantics of a public client.

Thoughts?

  -Josh

On May 24, 2013 11:35 AM, "Phil Hunt" <[email-masked]<mailto:[email-masked]>> wrote:
I wanted to bring out a quick discussion to ask the question if it makes sense to support implicit clients in dynamic registration.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[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

---

From: Josh Mandel <[email-masked]>
Date: Fri, 24 May 2013 13:40:47 -0700

I expect this is a non-starter, but dyn-reg *could* allow the client ti
include a "please expire me in xx min" flag in the registration request
(avoiding need for explicit cleanup later).

  -J

On Fri, May 24, 2013 at 1:36 PM, Richer, Justin P. <[email-masked]>wrote:

>  I agree with Josh, and I believe that this kind of application should
> definitely be supported. One of my goals with the Dynamic Registration
> draft was to make it so that it could be used for all the various flavors
> of OAuth that people are using today. But that said, I'm not at all against
> giving guidance to how and where to use it with these various flavors.
>
>  And regarding the DOS, one thing that the RESTful API here gives us is a
> means for well-behaved clients to clean up after themselves, where
> possible. Say the Blood Pressure Grapher is done with its session, it can
> call the Client Configuration Endpoint and DELETE itself, helping mitigate
> a flood of one-time-use client_ids. Doesn't necessarily help the case where
> the clients can't (or won't) clean up after themselves, or with a
> deliberate DOS, but there's a security consideration about throttling the
> registration endpoint already. Perhaps we should have something about "if
> the client_id hasn't been used in any grants in some amount of time, the AS
> should throw it away". But how long that is and at what level of client_id
> overpopulation the AS starts to care is way outside of the spec.
>
>   -- Justin
>
>  On May 24, 2013, at 4:21 PM, Josh Mandel <[email-masked]>
>  wrote:
>
> I have examples of client-side browser-based apps that fetch blood
> pressure values from the BlueButton+ API, and do some calculations /
> visualizations.  These apps need to run against any of a large collection
> of data holders (all of whom implement the same API endpoints), and may
> learn about new data holders in realtime from an end-user.
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 24 May 2013 21:14:45 +0000

I can see what you're trying to do there, but I agree that it's a bit of a non-starter. It assumes that clients even can be expired (which requires time-based processing of a client, not something most AS's are set up to do today, though it's far from impossible). And an in-browser client is likely to be bound to the user session. Would the client be allowed to refresh that value on an Update call in order to extend its lifetime, too?

If you want to define an extension for it (or even try it out inside of BB+), I think that makes the most sense.

 -- Justin

On May 24, 2013, at 4:40 PM, Josh Mandel <[email-masked]<mailto:[email-masked]>>
 wrote:

I expect this is a non-starter, but dyn-reg could allow the client ti include a "please expire me in xx min" flag in the registration request (avoiding need for explicit cleanup later).

  -J

On Fri, May 24, 2013 at 1:36 PM, Richer, Justin P. <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Josh, and I believe that this kind of application should definitely be supported. One of my goals with the Dynamic Registration draft was to make it so that it could be used for all the various flavors of OAuth that people are using today. But that said, I'm not at all against giving guidance to how and where to use it with these various flavors.

 -- Justin

Thoughts?

  -Josh

Phil

@independentid

---

From: John Bradley <[email-masked]>
Date: Fri, 24 May 2013 17:38:58 -0400

Phil,

I think the horse is out of the barn on implicit flow.

Many websites use implicit rather than code now, it is no worse, and perhaps better than using code flow with a client that is not confidential( though Dynamic registration can dix the public client code flow problem for native apps etc)

Implicit as you well know relies on registration of the redirect URI to identify the client.   There may be multiple JS apps in browsers all using JS from the same redirect URI, but I don't think that should preclude the backend website from using an API to register.    

Turning off dynamic registration entirely for implicit flow is overkill.   A registration server is free to not allow dynamic registration of implicit clients if that is it's policy.

In general I have a hard time seeing implicit clients with a server component using dynamic registration directly.   I suppose there may be HTML5 based clients that are loaded as browser extensions and use implicit, without having a server based redirect.   Those can be as long lived as any native app.  If clean up is an issue it is one for code flow as well.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 27 May 2013 11:46:41 -0700 (PDT)

John/Josh,

I am afraid it is still not clear to me what is the value of implicit client dynamic registration. If you allow dynamic registration of a client, each client, then each client can specify random redirect_uri's.  This would seem to be a major issue. The whole point behind implicit flow is NO client authentication.  So what technical or operational benefit of registering an execution instance?

Maybe, the horse has left the barn. But I don't see that as a reason to standardize an unsafe or pointless practice. I'm not saying it is pointless. I'm just not clear on what the benefit is. 

I am curious about Josh's use case.  How is the client code developed, distributed, and deployed?  Are there already inherent mechanisms where OOB deployment registration is easy to achieve?  IOW  Each client use can easily obtain an OOB client_id.   Josh expresses he needs to register, but the question I am asking is why?  It seems that in his case, the code being downloaded must be coming from a common trusted source. If so, what benefit is gained with dynamic registration for these clients. They should just use a static client_id -- even something akin to the initial client assertion Justin talks about.

From an operational aspect, issuing per execution context client_ids (and potential per client_id registration access tokens), etc per client seems to be wasteful for both the implicit client code and especially the AS/Resource SPs.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 May 2013 11:42:59 -0400

The main problem comes with establishing the client_id across multiple 
auth servers, not across multiple copies of the code. One of the key 
things that the DynReg spec does is establish a client_id for a client 
at an AS, and indeed the trigger condition for using it is generally 
"I'm a client and I don't have a client_id for an AS that I want to talk 
to".

Between yours and Torsten's comments, though, I think a discussion under 
the security considerations is a good idea.

  -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Tue, 28 May 2013 09:36:20 -0700

It is my strong opinion that giving each execution a client_id makes things much worse. 

Again now we cant tell who the risky players are since each client is anonymized through registration process. 

This is just not securable by any means. IMHO. 

Phil

On 2013-05-28, at 8:42, Justin Richer <[email-masked]> wrote:

> The main problem comes with establishing the client_id across multiple auth servers, not across multiple copies of the code. One of the key things that the DynReg spec does is establish a client_id for a client at an AS, and indeed the trigger condition for using it is generally "I'm a client and I don't have a client_id for an AS that I want to talk to".
> 
> Between yours and Torsten's comments, though, I think a discussion under the security considerations is a good idea.
> 
> -- Justin
>