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. 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
