On 14/08/13 05:24 PM, Bill Burke wrote:
On 8/14/2013 5:00 PM, Matt Wringe wrote:
> On Wed 14 Aug 2013 04:27:12 PM EDT, Bill Burke wrote:
>> On 8/14/2013 4:07 PM, Matt Wringe wrote:
>>> On Wed 14 Aug 2013 03:14:41 PM EDT, Bill Burke wrote:
>>>> On 8/14/2013 2:45 PM, Matt Wringe wrote:
>>>>> Thoughts on some possible ways to handle mobile aspects with
>>>>> Its just a very brief outline of some of the options to get a
>>>>> conversation started. I tried to brief as possible, but the email is
>>>>> still a bit long :/
>>>>> Mobile web app
>>>>> Works similar to how any normal web app would work with keycloak.
>>>>> changes really needed would be to make sure the login pages and
>>>>> such are
>>>>> designed to work properly on varying sizes of touchscreens.
>>>>> Native Mobile App Approaches
>>>>> 1)Native mobile app accessing keycloak through a custom webview.
>>>>> Its possible for a native application to create a webview and
>>>>> load the
>>>>> web components of keycloak through this. Requires some changes to
>>>>> keycloak to return the token to the application since using a normal
>>>>> redirect url isn't feasible.
>>>> On iphone you can redirect to and from native apps using URLs. So it
>>>> would be possible to use the Keycloak web login and redirects with
>>>> iphone. Are you sure Android doesn't have something similar?
>>> Yeah, you can of course use urls like that in Android.
>>> Normally the way its handled in this situation is to run web server on
>>> the device at localhost (which is what I meant by a normal url and why
>>> its not being really feasible) or to use a special redirect value and
>>> pass the token in a special manner (what you are suggesting).
>> Why the need for local webserver? ON iphone at least, the native app
>> would redirect to a keycloak.org
URL in browser
. Browser would do the facebook
>> login, then browser would redirect back to app with the access code
>> embedded within the URL. Then the app would make an internal HTTP
>> call to keycloak to obtain the token. Traditional OAuth. Don't see
>> why you need all the other tricks you are talking about...
>> Here's an example of using URLs to web provision a native app:
>> On iphone you can bind a protocol to an app, so keycloak would just
>> redirect to myapp://login?all&the&oauth¶meters&needed
> Hmm, interesting, its a nice clean way of handling it that I didn't
> really think of. I wonder why none the documentation on for how to
> perform social login on mobile devices mentions doing it this way.
Don't know. Maybe there is something I'm missing?? But I've seen
custom URLs work very nicely in iphone programming.
It must be something used more on iphone than android. I don't think I
have ever seen an application which opens a browser to perform a task
and then waits for a callback for it to complete. You can do it this
way, I have just never seen it used. Normally it more of a open way type
of thing, click this link and open this application. Then again, I just
may not be using the same types of mobile apps.
The only other thing I can think of why they don't do it this way is
that its kindof a weird situation when the token expires. The browser
would have to be opened again, but if the user is already authenticated
in the browser it would return a token right away. So to the user the
browser would open, maybe display a brief message about retrieving the
token, and then just close again. Using an embedded webview prevents
this, but then we run into the issues that a custom webview has.
> only downside is other than google, I don't think most people log into
> these sites using the mobile browser, they usually use the login via the
> mobile app.
Isn't it the same decision on whether to use a social library to help
you implement social login vs. a social broker hosted on another server?
What I meant here is that on my desktop browser I am already logged into
my social accounts. Since I am already logged in, when I access
something like keycloak, I just get a notification asking if I want to
grant keycloak authorization.
On my mobile devices, I use the mobile apps and not the browser. So when
I use something like keycloak in a mobile browser, I will be asked to
log into my social account first and then asked to grant keycloak
authorization. But this is really just one more step, which I don't
think is a big problem.
Why even have Keycloak for native mobile apps? They can use existing
native mobile app libraries to perform social login.
Why even have keycloak to begin with for any application. You can just
use existing sdks and app libraries for normal web sites as well. Any
argument for why a web application would want social login is going to
be exactly the same for a native application.
Native apps which would require social login are not just standalone
applications, if they were there would be no point in doing any sort of
login in the first place.
The native app is going to be communicating with a web application to
get and store information there. If my web application is using keycloak
to authenticate users, then my mobile app needs a way to authenticate
against it as well.
Normally what happens here is that the mobile app get the token from the
social provider and passes it to the web application. The web
application then verifies that the token is correct and uses it to
retrieve the users profile data on the social providers server. You
register both the web application and the native application with the
social provider as being the same client application, so that the token
from the native app can be used by the web app
Perhaps I am not explaining this very well or I am not understanding
Do facebook et. al. even have a direct non-browser, non-OAuth
There are two main native approaches, and they still use oauth:
1) still uses regular oauth, but instead of getting the token directly
from the social provider's authorization server you get it from the
account manager on the device (each social provider writes their own
authorization service which is still essentially contacting their
authorization server in the background). You still have provide what
scope you want and it will open a native UI asking for authorization if
you have not already granted it. Once you have this token, you use it
exactly the same was as you would on a web app.
2) uses an sdk to abstract out the oauth parts and automatically handles
error conditions and such. It makes it easier to developers to get
social integration up and running. Some, like facebook, are trying to
push using their sdk more exclusively though.