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
On 05/27/2013 02:46 PM, Phil Hunt wrote:
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 protected]
On 2013-05-24, at 2:38 PM, John Bradley wrote:
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.
On 2013-05-24, at 2:35 PM, Phil Hunt <[email protected]> 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.
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 protected]
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
