Subject: Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86

From: Erik Wahlström <[email-masked]>
Date: Fri, 24 Jul 2015 00:59:20 +0200

Hi,

Thanks for a great document! I volunteered to review
draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go:

In national mobile eID deployments an app is issued by gov or other
organisation in a country. The app acts as the users authentication method
and it works with an IDP, the IDP can be anywhere if its an PKI token or at
the place that issued the credential if it’s something else. When an SP
start developing an native app for there services and want’s to use the
national eID solution in combination with OAuth we might run into trouble
here.

The flow is like follows for a service provider called FooBar:

FooBar’s app starts browser-view. FooBar’s SAML service provider
functionality redirects the user to an national SAML IDP. The IDP prompts
user for a username and then starts an mobile eID token on the same phone.
Users is asked if they want’s to authenticate to FooBar and enters PIN.
User are then redirected back with an assertion. The FooBar's service
provider verifies the assertion and mint’s OAuth2 token(s) and redirects
the user back to the app with the help of the redirect URL.

So the phone first displays an app, then foobar.com <http://example.com/> in
browser-view, then idp.com <http://nationalidp.com/> in *browser-view*,
then mobile eID token, then idp.com <http://nationalidp.com/> in the *system
browser* and back to foobar.com <http://example.com/> and the app that the
user wanted to use.

The problem with browser-views is that the mobile eID token will start
idp.com when user has authenticated and then the user is not back in the
apps browser-view, but in system browser instead. The system browser is
sharing the session with the browser-view and redirect the user to the
native app. The user experience will be a bit strange then because there
the correct page is not loaded and the browser-view should be closed and
the app should start parsing out the authorization code instead.

So I think draft should mention something about this scenario and that app
developers should handle this scenario in the app. The grant did not really
come back from the browser-view as expected but from the system browser
instead.

—————————

With the above in mind. Maybe even some example code would be nice to have
in the non normative section "Appendix A.  Operating System Specific
Implementation Details”. Especially how to handle call backs.

—————————

Another eID related issue is the pricing model for authentications in that
market segment. It’s really common by the eID credential issuing
organisations to charge a service providers usage of a credential per tick
(that is by OSCP call). The system is based on a per tick pricing model and
there are regulations for how long the sessions can live. That means that
its not possible to authenticate with a token once and then create a
refresh token and the user will ever see the authentication flow again. It
kinda messes up the usability of mobile apps a lot but end users have come
to term with it. They have not however came to term to always require
consents every time they use the app. That drives end user crazy. The
usability would be much better if the payment model also accepted a refresh
token as a tick instead of just an OSCP call, but we are not there yet.

Anyway, that’s the backstory. The section "6.4.  Always Prompting for User
Interaction” is a bit harsh with a SHOULD NOT. I would rather change it to
a NOT RECOMMENDED.

—————————

Two additional things that strengthen the case for using the browser-view
also come to mind when reading the draft. The first is the fact that
multiple tabs is started in some browser when going through multiple
authentication attempts. That clutters the system so I really like the new
browser-views.

The second is that there are additionally nice things in browser-view that
do not exist in the web-view. The localStorage is also preserved and it can
include important information to make authentication methods more secure.

————————

"Authorization servers SHOULD consider taking steps to detect and

block logins via embedded user-agents that are not their own, where

possible.""

Sounds good, but that also sounds very hard when it comes to public
clients.

—————————

And some nits:

"OAuth flows between a native app and the system browser (or another

external user-agent) are more secure, and take advantage of the

shared authentication state."

Not really clear what shared authentication state that is in that sentence.

"When the authentication server completes the request, it redirects to

   the client's redirection URI like it would any redirect URI"

s/authentication/authorization

/ Erik

On Thu, Jul 23, 2015 at 6:22 PM, <[email-masked]> wrote:
>
>
> John Bradley and I introduced a new draft at IETF93 yesterday:
> https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00
>
>
> Goal is to provide best practices for native apps using the RFC6749
> authorization
> endpoint, expanding on RFC6749 Section 9.  Specifically, it recommends
> using an external user-agent (such as the system browser) for this task
> over an embedded user-agent (such as a web-view), and suggests ways to
> achieve this.
>
>
> Comments welcome!

---

From: John Bradley <[email-masked]>
Date: Fri, 24 Jul 2015 07:51:30 +0200

Thanks for the review Erik,

We will go through it in detail and get back to you.

I am working with a couple of governments on how a eID app could use the self issued profile of OpenID Connect to issue tokens.

There are also other out of band authentication  apps that people use that need to be considered.

I think that the callback / redirect_uri can work if a custom scheme URI or a app claimed https: URI is used.

I agree that sniffing the URI in a web view creates a very confusing user experience at the moment.  It works better on Android than iOS 8 but is not smooth in many cases.

I personally use a out of band mobile authenticator for my enterprise login that has exactly that problem, and requires me to manually switch back to the calling app.

Regards
John B.

> On Jul 24, 2015, at 12:59 AM, Erik Wahlström <[email-masked]> wrote:
> 
> Hi,
> 
> Thanks for a great document! I volunteered to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go:
> 
> 
> In national mobile eID deployments an app is issued by gov or other organisation in a country. The app acts as the users authentication method and it works with an IDP, the IDP can be anywhere if its an PKI token or at the place that issued the credential if it’s something else. When an SP start developing an native app for there services and want’s to use the national eID solution in combination with OAuth we might run into trouble here.
> 
> FooBar’s app starts browser-view. FooBar’s SAML service provider functionality redirects the user to an national SAML IDP. The IDP prompts user for a username and then starts an mobile eID token on the same phone. Users is asked if they want’s to authenticate to FooBar and enters PIN. User are then redirected back with an assertion. The FooBar's service provider verifies the assertion and mint’s OAuth2 token(s) and redirects the user back to the app with the help of the redirect URL.
> 
> So the phone first displays an app, then foobar.com <http://example.com/> in browser-view, then idp.com <http://nationalidp.com/> in browser-view, then mobile eID token, then idp.com <http://nationalidp.com/> in the system browser and back to foobar.com <http://example.com/> and the app that the user wanted to use.
> 
> The problem with browser-views is that the mobile eID token will start idp.com <http://idp.com/> when user has authenticated and then the user is not back in the apps browser-view, but in system browser instead. The system browser is sharing the session with the browser-view and redirect the user to the native app. The user experience will be a bit strange then because there the correct page is not loaded and the browser-view should be closed and the app should start parsing out the authorization code instead.
> 
> So I think draft should mention something about this scenario and that app developers should handle this scenario in the app. The grant did not really come back from the browser-view as expected but from the system browser instead. 
> 
> —————————
> 
> With the above in mind. Maybe even some example code would be nice to have in the non normative section "Appendix A.  Operating System Specific Implementation Details”. Especially how to handle call backs.
> 
> —————————
> 
> Another eID related issue is the pricing model for authentications in that market segment. It’s really common by the eID credential issuing organisations to charge a service providers usage of a credential per tick (that is by OSCP call). The system is based on a per tick pricing model and there are regulations for how long the sessions can live. That means that its not possible to authenticate with a token once and then create a refresh token and the user will ever see the authentication flow again. It kinda messes up the usability of mobile apps a lot but end users have come to term with it. They have not however came to term to always require consents every time they use the app. That drives end user crazy. The usability would be much better if the payment model also accepted a refresh token as a tick instead of just an OSCP call, but we are not there yet.
> 
> Anyway, that’s the backstory. The section "6.4.  Always Prompting for User Interaction” is a bit harsh with a SHOULD NOT. I would rather change it to a NOT RECOMMENDED.
> 
> —————————
> 
> Two additional things that strengthen the case for using the browser-view also come to mind when reading the draft. The first is the fact that multiple tabs is started in some browser when going through multiple authentication attempts. That clutters the system so I really like the new browser-views.
> 
> The second is that there are additionally nice things in browser-view that do not exist in the web-view. The localStorage is also preserved and it can include important information to make authentication methods more secure.
> 
> ————————
> 
> Sounds good, but that also sounds very hard when it comes to public clients. 
> 
> —————————
> 
> And some nits:
> 
> 
> 
> On Thu, Jul 23, 2015 at 6:22 PM, <[email-masked] <mailto:[email-masked]>> wrote:
> 
> https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 <https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00>
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 24 Jul 2015 07:00:33 +0000

hi,

nice to see some work on this topic by the way!

Couple of comments below inline

On Jul 24, 2015, at 7:51 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

Is there any example of “popular” custom scheme. One I have seen is urn:ietf:wg:oauth:2.0:oob
Another common redirect_uri for native app I have seen is http://localhost

One more comment. I strongly suggest  for mobile app to have a really strict consent screen policy.
Aka the authorization server MUST show the consent screen at every usage and not remember the fact that the app has been already authorized.

Just my 2 cents :)

regards

antonio

Regards
John B.

On Jul 24, 2015, at 12:59 AM, Erik Wahlström <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

So the phone first displays an app, then foobar.com<http://example.com/> in browser-view, then idp.com<http://nationalidp.com/> in browser-view, then mobile eID token, then idp.com<http://nationalidp.com/> in the system browser and back to foobar.com<http://example.com/> and the app that the user wanted to use.

The problem with browser-views is that the mobile eID token will start idp.com<http://idp.com/> when user has authenticated and then the user is not back in the apps browser-view, but in system browser instead. The system browser is sharing the session with the browser-view and redirect the user to the native app. The user experience will be a bit strange then because there the correct page is not loaded and the browser-view should be closed and the app should start parsing out the authorization code instead.

—————————

—————————

—————————

————————

possible.""

—————————

And some nits:

/ Erik

On Thu, Jul 23, 2015 at 6:22 PM, <[email-masked]<mailto:[email-masked]>> wrote:

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

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

---

From: John Bradley <[email-masked]>
Date: Fri, 24 Jul 2015 09:38:41 +0200

Hi Antonio,

Thanks for the feedback.

I agree that for non confidential clients, the user needs to be prompted.   It might be fair to just confirm the grants rather than resetting them from defaults.

I know some people are doing that, but I suspect that not everyone is.

Good stuff.

People should chime in with other things we need to consider.

Thanks
John B.

> On Jul 24, 2015, at 9:00 AM, Antonio Sanso <[email-masked]> wrote:
> 
> hi,
> 
> On Jul 24, 2015, at 7:51 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Another common redirect_uri for native app I have seen is http://localhost <http://localhost/>
> 
>>> On Jul 24, 2015, at 12:59 AM, Erik Wahlström <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi,
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 24 Jul 2015 16:44:06 +0900

Prompting is not necessarily is a good thing.
It is very context specific, so please do not make it required.

Nat

2015-07-24 16:38 GMT+09:00 John Bradley <[email-masked]>:

> Hi Antonio,
>
> Thanks for the feedback.
>
> I agree that for non confidential clients, the user needs to be prompted.
>   It might be fair to just confirm the grants rather than resetting them
> from defaults.
>
> On Jul 24, 2015, at 7:51 AM, John Bradley <[email-masked]> wrote:
>
> I am working with a couple of governments on how a eID app could use the
> self issued profile of OpenID Connect to issue tokens.
>
> Aka the authorization server MUST show the consent screen at every usage
> and not remember the fact that the app has been already authorized.
>
> Just my 2 cents :)
>
> regards
>
> antonio
>
>
> I agree that sniffing the URI in a web view creates a very confusing user
> experience at the moment.  It works better on Android than iOS 8 but is not
> smooth in many cases.
>
> I personally use a out of band mobile authenticator for my enterprise
> login that has exactly that problem, and requires me to manually switch
> back to the calling app.
>
> Regards
> John B.
>
>
>
>
> browser* and back to foobar.com <http://example.com/> and the app that
> the user wanted to use.
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Brian Campbell <[email-masked]>
Date: Fri, 24 Jul 2015 10:47:19 +0200

PCKE prevents a bad app from using the code when there's a collision in the
custom scheme used for the redirect URI. However the same app could
immediately issue a new authorization request with it's own PCKE parameters
and (mostly) transparently get back a code that it can use. Having some
user interaction via the browser helps mitigate that.

6.4 says that "tokens SHOULD NOT be issued to such [non-confidential]
clients without user consent or interaction" so it's not strictly required.

Also, FWIW from http://tools.ietf.org/html/rfc2119 SHOULD NOT and NOT
RECOMMENDED are effectively synonymous

On Fri, Jul 24, 2015 at 9:44 AM, Nat Sakimura <[email-masked]> wrote:

>> So I think draft should mention something about this scenario and that
>> app developers should handle this scenario in the app. The grant did not
>> really come back from the browser-view as expected but from the system
>> browser instead.
>>
>> —————————
>>
>> With the above in mind. Maybe even some example code would be nice to
>> have in the non normative section "Appendix A.  Operating System Specific
>> Another eID related issue is the pricing model for authentications in
>> that market segment. It’s really common by the eID credential issuing
>> Anyway, that’s the backstory. The section "6.4.  Always Prompting for
>> User Interaction” is a bit harsh with a SHOULD NOT. I would rather change
>> it to a NOT RECOMMENDED.
>>
>> —————————
>>
>> The second is that there are additionally nice things in browser-view
>> that do not exist in the web-view. The localStorage is also preserved and
>> it can include important information to make authentication methods more
>> secure.
>>
>> ————————
>>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 24 Jul 2015 19:27:57 +0900

Right, SHOULD NOT is fine. I am just asking not to make it a MUST NOT.

2015-07-24 17:47 GMT+09:00 Brian Campbell <[email-masked]>:

> PCKE prevents a bad app from using the code when there's a collision in
> the custom scheme used for the redirect URI. However the same app could
>>> I agree that for non confidential clients, the user needs to be
>>> prompted.   It might be fair to just confirm the grants rather than
>>> resetting them from defaults.
>>>
>>> I agree that sniffing the URI in a web view creates a very confusing
>>> user experience at the moment.  It works better on Android than iOS 8 but
>>> is not smooth in many cases.
>>>
>>> So the phone first displays an app, then foobar.com
>>> <http://example.com/> in browser-view, then idp.com
>>> <http://nationalidp.com/> in *browser-view*, then mobile eID token, then
>>>  idp.com <http://nationalidp.com/> in the *system browser* and back to
>>> foobar.com <http://example.com/> and the app that the user wanted to
>>> use.
>>>
>>> idp.com when user has authenticated and then the user is not back in
>>> the apps browser-view, but in system browser instead. The system browser is
>>> Two additional things that strengthen the case for using the
>>> browser-view also come to mind when reading the draft. The first is the
>>> fact that multiple tabs is started in some browser when going through
>>> multiple authentication attempts. That clutters the system so I really like
>>> the new browser-views.
>>>

---

From: Paul Madsen <[email-masked]>
Date: Fri, 24 Jul 2015 07:16:40 -0400

Antonio, are you arguing for short token lifetimes and so frequent 
explicit consent ? or something more

if the app has a valid refresh token then there is no opportunity for 
the AS to inject a consent screen

paul

On 7/24/15 3:00 AM, Antonio Sanso wrote:
>> I am working with a couple of governments on how a eID app could use 
>> the self issued profile of OpenID Connect to issue tokens.
>>
> Another common redirect_uri for native app I have seen is 
> http://localhost <http://localhost>
>
> Aka the authorization server MUST show the consent screen at every 
> usage and not remember the fact that the app has been already authorized.
>
> Just my 2 cents :)
>
> regards
>
> antonio
>
>>
>> user experience at the moment.  It works better on Android than iOS 8 
>> but is not smooth in many cases.
>>
>> login that has exactly that problem, and requires me to manually 
>> switch back to the calling app.
>>
>> Regards
>> John B.
>>
>>
>>
>>
>>> On Jul 24, 2015, at 12:59 AM, Erik Wahlström 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>> Hi,
>>>
>>> organisation in a country. The app acts as the users authentication 
>>> method and it works with an IDP, the IDP can be anywhere if its an 
>>> PKI token or at the place that issued the credential if it’s 
>>> something else. When an SP start developing an native app for there 
>>> services and want’s to use the national eID solution in combination 
>>> with OAuth we might run into trouble here.
>>>
>>> functionality redirects the user to an national SAML IDP. The IDP 
>>> prompts user for a username and then starts an mobile eID token on 
>>> the same phone. Users is asked if they want’s to authenticate to 
>>> FooBar and enters PIN. User are then redirected back with an 
>>> assertion. The FooBar's service provider verifies the assertion and 
>>> mint’s OAuth2 token(s) and redirects the user back to the app with 
>>> the help of the redirect URL.
>>>
>>> <http://nationalidp.com/> in *browser-view*, then mobile eID token, 
>>> then idp.com <http://nationalidp.com/> in the *system browser* and 
>>> back to foobar.com <http://example.com/> and the app that the user 
>>> wanted to use.
>>>
>>> The problem with browser-views is that the mobile eID token will 
>>> start idp.com <http://idp.com/> when user has authenticated and then 
>>> the user is not back in the apps browser-view, but in system browser 
>>> instead. The system browser is sharing the session with the 
>>> browser-view and redirect the user to the native app. The user 
>>> experience will be a bit strange then because there the correct page 
>>> is not loaded and the browser-view should be closed and the app 
>>> should start parsing out the authorization code instead.
>>>
>>> So I think draft should mention something about this scenario and 
>>> that app developers should handle this scenario in the app. The 
>>> grant did not really come back from the browser-view as expected but 
>>> from the system browser instead.
>>>
>>> —————————
>>>
>>> With the above in mind. Maybe even some example code would be nice 
>>> to have in the non normative section "Appendix A.  Operating System 
>>> Specific Implementation Details”. Especially how to handle call backs.
>>>
>>> —————————
>>>
>>> Another eID related issue is the pricing model for authentications 
>>> in that market segment. It’s really common by the eID credential 
>>> issuing organisations to charge a service providers usage of a 
>>> credential per tick (that is by OSCP call). The system is based on a 
>>> per tick pricing model and there are regulations for how long the 
>>> sessions can live. That means that its not possible to authenticate 
>>> with a token once and then create a refresh token and the user will 
>>> ever see the authentication flow again. It kinda messes up the 
>>> usability of mobile apps a lot but end users have come to term with 
>>> it. They have not however came to term to always require consents 
>>> every time they use the app. That drives end user crazy. The 
>>> usability would be much better if the payment model also accepted a 
>>> refresh token as a tick instead of just an OSCP call, but we are not 
>>> there yet.
>>>
>>> Anyway, that’s the backstory. The section "6.4.  Always Prompting 
>>> for User Interaction” is a bit harsh with a SHOULD NOT. I would 
>>> rather change it to a NOT RECOMMENDED.
>>>
>>> —————————
>>>
>>> browser-view also come to mind when reading the draft. The first is 
>>> the fact that multiple tabs is started in some browser when going 
>>> through multiple authentication attempts. That clutters the system 
>>> so I really like the new browser-views.
>>>
>>> The second is that there are additionally nice things in 
>>> browser-view that do not exist in the web-view. The localStorage is 
>>> also preserved and it can include important information to make 
>>> authentication methods more secure.
>>>
>>> ————————
>>>

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 24 Jul 2015 12:45:02 +0000

hi,

let me give you an example of what is my concern.
I admit this example is a bit extreme but still
As said one popular redirect_uri used by mobile app is http://localhost.

Let’s also say a resource owner use this mobile app the first time and approve the consent screen and so forth….

It also turn out this resource owner is a developer :) and it runs one application on its own computer.
This application runs as well on localhost.
Now, and as said this assumption is a bit extreme, this application has as well some open redirector and http://localhost?goto=http://evil.com redirect to evil.com<http://evil.com>

Well you can do your maths now and see that having a consent screen now would prevent such a threat

For the record some less popular custom redirect uri used for mobile I have seen is also data: so also this might be “at risk"

regards

antonio

On Jul 24, 2015, at 1:16 PM, Paul Madsen <[email-masked]<mailto:[email-masked]>> wrote:

Antonio, are you arguing for short token lifetimes and so frequent explicit consent ? or something more

if the app has a valid refresh token then there is no opportunity for the AS to inject a consent screen

paul

Is there any example of “popular” custom scheme. One I have seen is urn:ietf:wg:oauth:2.0:oob
Another common redirect_uri for native app I have seen is http://localhost<http://localhost/>

Just my 2 cents :)

regards

antonio

Regards
John B.

Hi,

—————————

—————————

—————————

————————

possible.""

—————————

And some nits:

/ Erik

Comments welcome!