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:
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 <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
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.
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>
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
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
<e...@wahlstromstekniska.se <mailto:e...@wahlstromstekniska.se>> 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.
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 <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.
————————
"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, <oauth-requ...@ietf.org
<mailto:oauth-requ...@ietf.org>> 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!
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
