Hi John,
On 27/08/13 13:00, John Bradley wrote:
Typically native apps on smart phones use the code flow and a redirect_uri with
a custom scheme to redirect the browser back to the app with the query encoded
code.
The native app is a public client as it cannot keep a secret, unless it is
using dynamic registration.
The ID Nat and I put together is a proposed way that a proof of possession for
the code can be used as an alternative to registering every instance of a
native app.
On iOS and android multiple apps can register the same custom scheme and may
try to intercept the code which can be used if the client_id and secret are
known.
Thanks for the explanation, helpful; one thing I'd like to clarify, in
such cases (where no every instance of the application is dynamically
registered), the native application needs to be registered once and have
this redirect uri with a custom scheme pre-registered, right ?
I'm assuming it is the case (redirect uri must be pre-registered, no
difference here between public and confidential clients as far as the
treatment of redirect uris is concerned), but if not then I'd appreciate
some clarifications
Cheers, Sergey
John B.
On 2013-08-27, at 6:54 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
Hi
I am a bit confused on whether public clients such as smart phones, etc which
work with the authorization code flow can have redirect URIs supported or not.
My understanding so far has been that public clients won't have redirect uris
(except for them working with Implicit code flows), the code would be entered
into the device by a user or perhaps returned directly from AS via some back
channel. The reason I ask is the text at [1] says in its Introduction:
"... This is especially true on some smartphone platform in which the 'code' is
returned to a redirect URI ..."
I can imagine that in this case a smartphone has an application actually
running a web server so it can accept redirect requests,
is it when public clients can have redirect URIs and texts such as [1] can be
of help ?
Thanks. Sergey
[1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-01
_______________________________________________
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
