[Openid-specs-native-apps] IOS 8 interapp messaging
Paul Madsen
paul.madsen at gmail.com
Wed Jun 4 10:45:51 UTC 2014
trying to understand where Nat's spec fits here.
The TCSEspec requires an two-stage code-style flow as opposed to a
single-stage implicit-style flow
As I see it, there are logically two client-server interactions here
1) that between app & TA (nee AZA)
2) that between the TA and the AS
Both could theoretically be either code or indirect style (though #2
will be code so we don't rule out TA authentication to the AS)
So we end up with the following permutations
*1) Implicit & implicit*
AS TA App
<--- request ----
<---- request -----
------- token ------>
----- token ----->
*2) Implicit & Code*
AS TA App
<--- request ----
<---- request -----
-------- code ------>
<------ code -------
------- token ------>
----- token ----->
*3) Code**& implicit *
AS TA App
<--- request ----
<---- request -----
------- token ------>
------ code ----->
<---- code ------
----- token ----->
*4**) Code & Code*
AS TA App
<--- request ----
<---- request -----
-------- code ------>
<------ code -------
------- token ------>
------ code ----->
<---- code ------
----- token ----->
TCSE could protect against an attacker app, having squatted on the
custom URL of the legit app, stealing the code returned by the TA in
Options #3 & #4 above.
TCSE does not apply in an 'IdP init' model where the application is
launched from a UI provided by the TA.
paul
On 6/3/14, 12:03 PM, Chuck Mortimore wrote:
> Did some work on this at Salesforce over the last couple weeks.
>
> When calling aza, on iOS the app is able to determine calling app
> identity by an injected bundle id. On Android you can get a cert
> hash. Both are OS asserted so are relatively secure assuming a
> non-jailbroken device. There doesn't seem, at least on iOS, to be
> a good way from preventing hijacking of the aza's custom scheme, so
> this is likely susceptible to at least some sort of phishing
>
> As far as callbacks back into the requesting app, we've looked at two
> approaches. Either Nat's
> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 as well as
> issuing an ephemeral public/private key, passing the public key in the
> request, and encrypting the response. Both seem to work well enough
> for protection against hijacked callbacks. At this point, we're
> heading towards the former given the relative simplicity.
>
> -cmort
>
>
>
> On Tue, Jun 3, 2014 at 8:18 AM, Paul.madsen <paul.madsen at gmail.com
> <mailto:paul.madsen at gmail.com>> wrote:
>
> Writ the URL scheme mechanism, has anybody done the exercise of
> assessing the associated security characteristics in Android and iOS?
>
>
> Sent from my Samsung Galaxy smartphone.
>
>
> -------- Original message --------
> From: Lloyd Burch
> Date:06-03-2014 11:00 AM (GMT-05:00)
> To: paul.madsen at gmail.com <mailto:paul.madsen at gmail.com>,
> openid-specs-native-apps at lists.openid.net
> <mailto:openid-specs-native-apps at lists.openid.net>
> Subject: Re: [Openid-specs-native-apps] IOS 8 interapp messaging
>
> I have now watched it three time and am looking for more
> information on the details.
> What I would like to know is, can the called and calling
> application know the ID of each other and can that be validated
> via iOS?
> Using the URL Schema calls is a little SLOW, but it is all we have
> now. This should fix this.
> Lloyd
>
>
> >>> Paul Madsen <paul.madsen at gmail.com
> <mailto:paul.madsen at gmail.com>> 6/2/2014 1:42 PM >>>
> >http://www.theverge.com/2014/6/2/5773080/ios-8-apps-can-talk-to-each-other
> perhaps relevant to mobile binding spec
> paul
>
> _______________________________________________
> Openid-specs-native-apps mailing list
> Openid-specs-native-apps at lists.openid.net
> <mailto:Openid-specs-native-apps at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140604/1152094d/attachment-0001.html>
More information about the Openid-specs-native-apps
mailing list