[keycloak-dev] Keycloak and mobile

[Matt Wringe]

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 
>>>>>> Keycloak.
>>>>>> 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. 
>>>>>> Only
>>>>>> 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
>>> http://keycloak.org/client_id=...  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:
>>>
>>> http://code.google.com/p/oathtoken/wiki/WebProvisioning
>>>
>>> On iphone you can bind a protocol to an app, so keycloak would just
>>> redirect to myapp://login?all&the&oauth&parameters&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.

>
>> The
>> 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 
(cross-client/cross-platform authentication).

Perhaps I am not explaining this very well or I am not understanding 
your questions.

> Do facebook et. al. even have a direct non-browser, non-OAuth approach 
> to login?

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.