Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

From: Francisco Corella <[email-masked]>
Date: Fri, 1 Apr 2011 11:24:21 -0700 (PDT)

Hi Prateek,

> I would like to strongly disagree with this proposal.
> 
> It amounts to explicitly making OAuth 2.0 insecure so as to
> satisfy some mysterious and unspecified set of legacy OAuth
> 1.0 deployments.
> 
> The SAML web SSO (artifact) profile - which shares many
> characteristics with the initial steps in OAuth - requires
> precisely such a counter-measure and is widely implemented
> in 1000s of deployments.

What counter-measure is this?  Can you provide a reference?
Section 4.1.3.5 of 
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
recommends TLS but does not require it.

Francisco

---

From: Prateek Mishra <[email-masked]>
Date: Mon, 04 Apr 2011 11:57:32 -0400

Francisco,

You are right, I was in error to suggest that it was a MUST.

 I think my main concern was that security considerations should not be 
based on polling developers/deployers of an existing or legacy protocol.

SAML does include some additional countermeasures though - for example 
(lines 595-596, profiles document) - that specifically deal with the
artifact being leaked -

[quote]
The identity provider MUST ensure that only the service provider to whom 
the <Response> message has
been issued is given the message as the result of an <ArtifactResolve> 
request.
[\quote]

- prateek

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 09:52:17 -0700

Apologies for the long message (again). I have attempted to sum things up and bring out the issue without using any existing service or party as an example of problems. It seems some have taken offence to my previous message pushing for a solution. As a result it was not productive. I apologize.  Hopefully this message sticks to the issue of developing an appropriate counter measure to threats as that is my only intent.

As Prateek clarified in the previous message to Francisco, SAML also uses SHOULD, but artifact security is achieved by an additional counter-measure...
> The identity provider MUST ensure that only the service provider to whom the <Response> message has
> been issued is given the message as the result of an <ArtifactResolve> request.

Yet, in OAuth the client app is not unique for a particular set of client credentials we currently have no way to verify that the correct client got the code. This has been the mechanism that the community has been assuming solves the problem. Client credentials do not always work to protect the authorization code because in OAuth you can have many many clients with the same credential. For example everyone with the same mobile app likely has the same client credential. Thus a copy of a valid client app which is easy to obtain becomes the hacker's attack vector. So, the client credential is not an effective counter in this case.

Several have commented that there are other supplementary techniques for protection, but in my view, most of them work indirectly and/or depend on correct collective configuration of several components. Some of these are: tokens may be used one time; tokens are invalidated if used a second time, tokens are sufficiently unique, etc.  All of these will help. But none are designed to directly counter the attack. In fact the best one - token invalidation carries the additional problem of unreliable service for the legitimate client. The hacker can deny service to anyone in the room simply by re-using any tokens seen.

From my perspective, the "easy" solution was to increase the requirements on TLS from SHOULD to MUST to prevent eavesdropping of the code. This was echoed by several others. I agree this will not work for everyone. Many have made strong arguments for why they can't use it. But without a MUST we are still missing a direct counter to the threat.

I don't want to change things at this late date, but maybe this means introducing some form of mutual authentication -- some way for the requesting client "instance" to prove that they are the copy eligible to use an authorization code. 

To end this discussion, I propose we vote on the proposal from Eran plus one new option...
1. Include a normative MUST use TLS for the client redirection URI endpoint.
2. Include a normative SHOULD use TLS for the client redirection URI endpoint with strong language explaining the various attacks possible if the endpoint is not made secure.
3. Keep current language of SHOULD, but develop a direct counter-measure to token theft such as specific client instance identification or mutual authentication.

Phil
[email-masked]

On 2011-04-04, at 8:57 AM, Prateek Mishra wrote:

>  I think my main concern was that security considerations should not be based on polling developers/deployers of an existing or legacy protocol.
> 
> SAML does include some additional countermeasures though - for example (lines 595-596, profiles document) - that specifically deal with the
> artifact being leaked - 
> 
> [quote]
> The identity provider MUST ensure that only the service provider to whom the <Response> message has
> been issued is given the message as the result of an <ArtifactResolve> request.
> [\quote]
> 
> - prateek
>> Hi Prateek,
>>

---

From: Brian Eaton <[email-masked]>
Date: Mon, 4 Apr 2011 10:11:02 -0700

On Mon, Apr 4, 2011 at 9:52 AM, Phil Hunt <[email-masked]> wrote:

> As Prateek clarified in the previous message to Francisco, SAML also uses
> SHOULD, but artifact security is achieved by an additional
> counter-measure...
>
> The problem with the SAML comparison is that SAML does not attempt to
address the problems of installed applications.  That was all deferred to
WS-Trust.  OAuth2 does solve both the web app and installed app problems.

I think it's really important that we recognize that installed applications
have a very different set of security problems than web sites.  For example,
for web sites we need to deal with the risk of RP compromise and all of the
refresh tokens being stolen.  That's not an issue for installed apps,
because there is no central database of refresh tokens to compromise.  For
installed apps, on the other hand, there is no good system for reliably
identifying a client.  For web apps we've got two separate good systems
(same-origin policy and client secret) for identifying RPs.

One other interesting aspect of client applications is that it's very easy
for client apps to use a protected channel to receive the callback URL.
 There is lively debate about which protected channel to use, but almost
everyone agrees there is at least one good option.

If you redo your analysis from the perspective that client applications have
different security risks than web applications, do you reach happier
conclusions?

Cheers,
Brian

---

From: Oleg Gryb <[email-masked]>
Date: Mon, 4 Apr 2011 10:52:34 -0700 (PDT)

After looking into exiting (and working) implementations of OAuth 1.0 in mobile 
world I have strong doubts about possibility of implementing what was suggested 
in option #3. 

In my view, two conditions are needed to achieve that:

1. Something unique stored on a mobile client.
2. That something should be a secret, so other (malicious) clients could not 
reuse it.

Distribution of that "unique secrets" should be automated in the mobile world 
and is usually included to mobile application 

activation process, but that activation process can't make conditions 1 & 2 
above met in full, becuase:

1. As soon as secrets are distributed to a mobile device they are not quite 
secret any more
2. As soon as the secret becomes known, a simulator or other mobile device can 
be used to spoof the traffic

I would consider option #3 as an illusion until somebody comes up with a 
solution that would address the described issues.

BTW, the draft of "OAuth Dynamic Client Registration Protocol" 
(http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on Feb. 12 
and I didn't see any attempts to re-vitalise it. I think it would be better and 
more beneficial for the community to return to this protocol rather than 
inventing a new method of "mutual authentication". 

>
>From: Phil Hunt <[email-masked]>
>To: Prateek Mishra <[email-masked]>
>Cc: OAuth WG <[email-masked]>
>Sent: Mon, April 4, 2011 9:52:17 AM
>Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)
>
>
>Apologies for the long message (again). I have attempted to sum things up and 
>bring out the issue without using any existing service or party as an example of 
>problems. It seems some have taken offence to my previous message pushing for a 
>solution. As a result it was not productive. I apologize.  Hopefully this 
>message sticks to the issue of developing an appropriate counter measure to 
>threats as that is my only intent.
>
>
>SHOULD, but artifact security is achieved by an additional counter-measure...
request.

>Yet, in OAuth the client app is not unique for a particular set of client 
>credentials we currently have no way to verify that the correct client got the 
>code. This has been the mechanism that the community has been assuming solves 
>the problem. Client credentials do not always work to protect the authorization 
>code because in OAuth you can havemany many clients with the same credential. 
>For example everyone with the same mobile app likely has the same client 
>credential. Thus a copy of a valid client app which is easy to obtain becomes 
>the hacker's attack vector. So, the client credential is not an effective 
>counter in this case.
>
>
>Several have commented that there are other supplementary techniques for 
>protection, but in my view, most of them work indirectly and/or depend on 
>correct collective configuration of several components. Some of these are: 
>tokens may be used one time; tokens are invalidated if used a second time, 
>tokens are sufficiently unique, etc.  All of these will help. But none are 
>designed to directly counter the attack. In fact the best one - token 
>invalidation carries the additional problem of unreliable service for the 
>legitimate client. The hacker can deny service to anyone in the room simply by 
>re-using any tokens seen.
>
>
>From my perspective, the "easy" solution was to increase the requirements on TLS 
>from SHOULD to MUST to prevent eavesdropping of the code. This was echoed by 
>several others. Iagree this will not work for everyone. Many have made strong 
>arguments for why they can't use it. But without a MUST we are still missing a 
>direct counter to the threat.
>
>
>I don't want to change things at this late date, but maybe this means 
>introducing some form of mutual authentication -- some way for the requesting 
>client "instance" to prove that they are the copy eligible to use an 
>authorization code. 
>
>
>2. Include a normative SHOULD use TLS for the client redirection URI endpoint 
>with strong language explaining the various attacks possible if the endpoint is 
>not made secure.
>3. Keep current language of SHOULD, but develop a direct counter-measure to 
>token theft such as specific client instance identification or mutual 
>authentication.
>
>
>Phil
>[email-masked]
>
>
>
>
>> I think my main concern was that security considerations should not be based on 
>>polling developers/deployers of an existing or legacy protocol.
>>
>>SAML does include some additional countermeasures though - for example (lines 
>>595-596, profiles document) - that specifically deal with the
>>artifact being leaked - 
>>
>>[quote]
request.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 11:23:13 -0700

I have been wondering if we can combine a couple of things such as a client generated transaction secret and use limited TLS to achieve a fix.  Note: this would address a hacker sniffing a returned authorization code, but it probably does little for the MITM scenario that was also outlined.

1. The client app generate a random number or sequence of characters, lets call it "request_id", then that value would be included and securely (using TLS) transmitted in the authorization request.
2. The authorization server does its usual thing and returns, preferably securely but not necessarily, the authorization code to the client app.
3. Upon requesting an access_token, the client app also includes the same request_id in its secure request to the token endpoint.
4. The token server verifies that the "request_id" matches the request_id supplied in the authorize request (in addition to all the other processing).

Since both requests are sent securely a sniffing client cannot obtain the client request_id even though it might be able to obtain the authorization code being returned.

What this might allow is that the client can transmit a secret protected by TLS in its outbound request, but can accept non-secure delivery of the authorization code.  The token server then has a means to verify that the client exchanging the authorization code is the same one that made the initial request.

This is off the top of my head, I am sure the proposal is likely not yet a complete solution, but maybe someone can build on that.

Phil
[email-masked]

On 2011-04-04, at 10:52 AM, Oleg Gryb wrote:

> After looking into exiting (and working) implementations of OAuth 1.0 in mobile world I have strong doubts about possibility of implementing what was suggested in option #3. 
> 
> 2. That something should be a secret, so other (malicious) clients could not reuse it.
> 
> Distribution of that "unique secrets" should be automated in the mobile world and is usually included to mobile application 
> activation process, but that activation process can't make conditions 1 & 2 above met in full, becuase:
> 
> 1. As soon as secrets are distributed to a mobile device they are not quite secret any more
> 2. As soon as the secret becomes known, a simulator or other mobile device can be used to spoof the traffic
> 
> I would consider option #3 as an illusion until somebody comes up with a solution that would address the described issues.
> 
> BTW, the draft of "OAuth Dynamic Client Registration Protocol" (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on Feb. 12 and I didn't see any attempts to re-vitalise it. I think it would be better and more beneficial for the community to return to this protocol rather than inventing a new method of "mutual authentication". 
> 
> 
> 
>

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 4 Apr 2011 14:47:44 -0400

How does the client app transmit the nonce (random number) to the web browser for redirect to the provider? If the client app does not support HTTPS, it can't set up a secure session on its own to give the browser/user something to pass on during the provider authorization.

To me, this is nothing different that a unique value of "state" which robust clients will already use to differentiate request flows. Such a state variable would be exposed both on its way and back of the provider's redirect.

In any case, I see HTTPS as the simple solution here. I question if it is in the scope of OAuth to provide a mechanism to the community to protect against such MITM attacks between a hosted web application and the web browser.  If the nature of the data requires such protection, the app developer (or the provider) can work to provide such security outside of HTTPS.  In the right context, tunneling customer traffic through a provider-provided VPN could be considered a reasonable protection for the cases folks have outlined.  It just doesn't seem like a popular need at this point, and there seem to be no easy wins for hosted clients unable to register with a certificate authority.

On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phillip Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 12:03:38 -0700

It doesn't require client side ssl. 

Phil

Sent from my phone.

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 4 Apr 2011 15:08:12 -0400

Maybe you can explain your example in more detail then? I'm assuming your "client app" is a web application hosted on web server supporting only HTTP.

How does the nonce or request_id get to the provider as part of the authorization request in your example?  (step 1)

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 12:12:30 -0700

I was referring to a mobile client that passes the request via an external browser. That browser is capable of running SSL with server authentication only.

Phil
[email-masked]

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 4 Apr 2011 15:28:28 -0400

But mobile clients aren't vulnerable to this type of attack because all of their code is contained on the device and they make all outgoing requests to the provider via SSL.  There are no redirects to insecure remote endpoints.  A mobile device incapable of making outgoing SSL requests would not be able to run an OAuth-compliant client as the spec is currently written.

Where in this example is the un-encrypted exchange you are trying to protect?

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 12:38:55 -0700

If you run a scanner, you will see that many of the current draft implementations pass the authorization code by redirect without SSL. I've seen several implementations where the authorization code is easy to scan.

I suspect this occurs because the HTTP response isn't directly in response to the original outgoing authorization. When I run the scanner, the resource provider is performing a workflow with the user that accomplishes form based authentication and authorization with the user, some of which is not on SSL. What happens is the redirect is then not sent by SSL. It seems like only a natural consequence of typical authentication/authorization workflows. Or at best, it is difficult the guarantee that the authorization code will always be returned in a secure TLS channel.

Several people stated that the redirect end-point cannot implement server-side security (called local redirect) and I think their request is reasonable as it would require each client to have its own server certificate. That *might* be acceptable to most web apps, but likely won't work for apps with many many copies like mobile apps.

So, I'm making the assumption that if we can minimally count on outbound TLS security, the transaction id would suffice to allow the token service to connect the originating authorization client with the client requesting an access token.

Phil
[email-masked]

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 4 Apr 2011 15:52:59 -0400

I'm confused - it seems like you're mixing web clients and native clients in this most recent explanation.  It's perfectly reasonable that the authorization code will always be returned by a provider in a secure TLS channel to the web browser or native client which started the authorization request.  What's not reasonable is, in the case of the code returned to a web browser (acting on behalf of a web client), for the browser to then pass the code on to the web client over TLS.

Maybe you can elaborate the attack you are considering by listing each network request/response between the mobile client and any servers?

I'll repeat again that the attack I've seen described thus far doesn't apply to mobile apps with( or without) many copies because there is no local redirect involved. (The redirect URI is merely an identifier that says "here's the code!" - it need not be a network location, and if it is, it's just a local location on the same device - eg, another app running on the same device).

skylar

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 13:06:53 -0700

For the moment, I'm only talking about mobile clients.

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.
2) Evil Brian intercepts the (HTTP) redirect containing Paul's authz code
3) Brian takes Paul's redirect #2 and enters it in his browser (e.g. by script)
4) Brian's browser processes redirect URI from #3 and passes to Brian's copy of client (e.g. downloaded from app store).
5) Brian's client exchanges substituted authz code for access token
6) Brian's client now accesses service using Paul's authorization

As was explained earlier this attack is minimized by things like token invalidation when the second client comes along, but we still have a horserace and possibility of DoS for the user at minimum.

The server cannot mitigate this unless it can either ensure the client is the only one that could have received the code, or can somehow uniquely identify the client so that a copy cannot masquerade as the original requestor.

Phil
[email-masked]

---

From: Brian Eaton <[email-masked]>
Date: Mon, 4 Apr 2011 14:00:23 -0700

> 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Apr 2011 14:30:27 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Eaton
> Sent: Monday, April 04, 2011 2:00 PM
> To: Phil Hunt
> Cc: Oleg Gryb; OAuth WG
> > 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:
> 

Not at all. Just as a matter of "standards etiquette" we can't explicitly recommend violating other standards. The only issue is using unregistered schemes.

EHL

>    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

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 4 Apr 2011 21:39:42 -0400

> 1) Paul starts dance at good Client &  good AS, App requests authorization. Note: outbound call is secure, but returned redirect is not.

I'm going to re-iterate Brian's point that this is not an interesting attack because we have no problem with securing a response to the outbound call. Just to be very clear that we're all speaking about the same thing here I'm detailing what you are implying in step one (assuming pop-out to external browser as you mentioned earlier in this thread):

- Paul's mobile device (MD), running native client C, makes request to the mobile browser (MB) on the same device for the OAuth authorization page for provider P.
- The MB makes an outbound request over TLS to P's outh/authorization endpoint. (HTTPS)
- P responds over the same socket with the approval (and or login pages). (still HTTPS)
- Paul clicks the Approval button on the provider authorization page which initiates MB to make a new HTTPS call confirming the approval.
- MB responds on the same secure socket (HTTPS!) with the composed redirect URI including auth code.  Note here that the redirect URI uses a custom protocol since the authorization is happening in an external browser (not embedded in the client).  This looks like something x-application-myapp://oauth-callback?code=secret
- MB handles the redirect URI by opening the native client C, passing it the redirect URI from the previous step. This is a secure transfer of data between two apps on MD.

This is the only flow on the table for a native mobile app using auth codes and an external browser. All exchanges between clients (C and MB) and server are over TLS. There is no MITM or sniffing exploit for this flow.

For an embedded browser flow, the flow is similarly secure as Brian took care to describe.  The redirect URI might be an URN, a custom URI, or an HTTPS url.

For an intercept to happen as you've outlined in step 2, MB or native client C must make a **new** network connection to some yet-to-be-identified server.  To me, it seems beyond obvious that the redirect response from the provider's authorization server would be secured over the same socket that started the authorization. If the authorization server redirects to itself using an HTTP url which then responds with the redirect URI, that is a poorly implemented authorization server and would be non-complient according to the spec.  That's sloppy coding, not a sloppy spec.

So, this leaves us no identified security compromise for the native mobile client, thus no need for further measures to secure this flow.

Whew.

---

From: Phillip Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 20:30:24 -0700

Phil

Sent from my phone. 

> - P responds over the same socket with the approval (and or login pages). (still HTTPS)
Not guaranteed by spec nor in practice. 
> - Paul clicks the Approval button on the provider authorization page which initiates MB to make a new HTTPS call confirming the approval.

Again not in practice. 
> - MB responds on the same secure socket (HTTPS!) with the composed redirect URI including auth code.  Note here that the redirect URI uses a custom protocol since the authorization is happening in…
My scanner is showing this is not happening. Moreover the spec only says it is a SHOULD per the discussion. 

This is the point that is often trivial to eavesdrop and easy to pass into Brian's browser. The browser does the rest of the hack all by itself by following the link. 
> - MB handles the redirect URI by opening the native client C, passing it the redirect URI from the previous step. This is a secure transfer of data between two apps on MD.

Agreed. 
> This is the only flow on the table for a native mobile app using auth codes and an external browser. All exchanges between clients (C and MB) and server are over TLS. There is no MITM or sniffing e…
Only true if TLS is on. 
> For an intercept to happen as you've outlined in step 2, MB or native client C must make a **new** network connection to some yet-to-be-

Remember the token request is a NEW endpoint. 
> identified server.  To me, it seems beyond obvious that the redirect response from the provider's authorization server would be secured over the same socket that started the authorization. If the authorization server redirects to itself using an HTTP url which then responds with the redirect URI, that is a poorly implemented authorization server and would be non-complient according to the spec.  That's sloppy coding, not a sloppy spec.

I think you are over complicating. Look at the Facebook implementation (No offense to Facebook) and watch with a scanner. 
> So, this leaves us no identified security compromise for the native mobile client, thus no need for further measures to secure this flow.

Well the hack works just fine for me. I really wish you were correct. :)

---

From: Skylar Woodward <[email-masked]>
Date: Tue, 5 Apr 2011 00:13:44 -0400

Wow. I can't believe we're having this debate. You're describing a failed implementations, not the spec.  I think you are also misunderstanding the implementation of this client flow.  Have you built a sample client with this flow?

I'm going respond to these points, but if there's still confusion, I'm going to need someone else to defend your argument. I'm either completely misunderstanding the case you're presenting, or you are.

See inline...

> Not guaranteed by spec nor in practice. 

The response is over the same SSL-protected connection which MB initiated to P. It's a simple HTTP response to an HTTP request. There's no way the client can't respond over TLS.... unless there's a feature of SSL with which I'm not familiar that allows a peer to negotiate the socket as insecure mid-communication without forcing the other peer to close the socket.  (If that actually exists, you'll have to show me the API in OpenSSL that would even allow a provider to implement such behavior - otherwise I'll never believe it. Then, show me the API call in Apache that allows that same [useless] behavior for an HTTP response handler.).

P would have to redirect MB to a new URL on P which is not accessed via HTTPS. That's not part of this discussion. No one is proposing it and the spec forbids it with respect URLs on the Authorization Server.

The authorization server MUST require TLS 1.2 for the Authorization Endpoint as per item 2.1.

>> - Paul clicks the Approval button on the provider authorization page which initiates MB to make a new HTTPS call confirming the approval.

Please stop talking about practice. No one on this list is proposing redirecting from the authorization endpoint to an insecure page before sending the redirect + auth code.  If you've discovered a faulty implementation, please discuss this with that implementor.

> My scanner is showing this is not happening. Moreover the spec only says it is a SHOULD per the discussion. 

Here, you may be evaluating a faulty client. Please discuss this with the developer of the client you are evaluating.

There is no option here (regardless of the language SHOULD). If the client developer doesn't use a custom protocol handler which is registered, the client application on the device will never get the callback. For the flow to work, a custom URL scheme must be used.

(Besides, I don't see any language limiting the scheme for URIs. Only that the redirection URI be a URI and *should* be pre-registered or otherwise trusted.  But the point is moot for this flow. It must be a custom app protocol registered to be handled by client C.)

>> This is the only flow on the table for a native mobile app using auth codes and an external browser. All exchanges between clients (C and MB) and server are over TLS. There is no MITM or sniffing…

This comment doesn't make sense. We've established that all communication in this flow is over secured SSL channels.

> Remember the token request is a NEW endpoint. 

What does this comment even mean?! What is it one is meant to remember?  The token request has never been in question. It must support TLS 1.2 (per section 2.2) and the server is known: it's still provider P. 

> I think you are over complicating. Look at the Facebook implementation (No offense to Facebook) and watch with a scanner. 

Facebook has nothing to do with evaluating this flow. If you feel some mobile client interaction with a Facebook API demonstrates this well you should explain the flow and also demonstrate that the Facebook-hosted provider you are evaluating is compliant with the latest draft of the spec.  I'm confident you would find the client or server non-compliant, or that you are in fact describing a flow different from that of the native mobile client + external browser.

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 5 Apr 2011 16:35:55 -0700

We have native clients using the first 3 as well with good success

-cmort

On 4/4/11 2:00 PM, "Brian Eaton" <[email-masked]> wrote:

Cheers,
Brian