We have native clients using the first 3 as well with good success
-cmort
On 4/4/11 2:00 PM, "Brian Eaton" <bea...@google.com> wrote:
On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt <phil.h...@oracle.com> wrote:
> Very quickly here is the attack...
> 1) Paul starts dance at good Client & good AS, App requests authorization.
> Note: outbound call is secure, but returned redirect is not.
For the record, we haven't had particular problems with installed apps
finding secure callback URLs. We've got mobile clients using the
following approaches:
- using custom URL schemes.
I gather this is forbidden by spec, but it prevents the attack at least.
- using https URLs hosted at Google, in a web view
Mobile apps watch the URL (you can do this with embedded web views)
and read the authorization code that way.
- using https URLs hosted at third-party web sites, in a web view
These are typically static or very simple web sites that are used
just to transfer control back to the mobile app.
- using https URLs hosted at Google, in the default browser rather
than a web view
There are various tricks that you can use to pick up the
authorization code from the default browser. They are all ugly, but
they work.
Cheers,
Brian
_______________________________________________
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
