[feedhenry-dev] Authentication in Mobile.Next

[Summers Pittman]

It sounds like between the meeting and this thread we have some really good
lines of investigation to pursue.

If you guys are up for it, we can have a meeting tomorrow ~1430 (0930 ET)
 and fill out some spikes in a jira portfolio to begin actual work.

Ping me on this thread, IRC, or slack and I will send you a meeting invite.


On Fri, Aug 25, 2017 at 12:08 PM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On Fri, Aug 25, 2017 at 10:33 AM, Wei Li <weil at redhat.com> wrote:
>
>> Hi FeedHenry developers,
>>
>> As you may have heard, we are planning on delivering a few mobile-focused
>> services in Mobile.Next project. One of the services we are looking at is
>> authentication.
>>
>> As a start, we first would like to kick off some discussions around
>> requirements & expectations of this service within the community. More
>> specifically, we are looking for some answers to the following questions:
>>
>> * What is the biggest pain point you currently have in terms of user
>> authentication when develop mobile applications?
>>
>
> My biggest pain is integrating in various social providers in a way that
> is compatible and not clunky,
>
> For a new app there is an understood Register -> Confirm Registration ->
> Log In -> Use the app flow.  Social providers through OAuth combine the
> first three steps into a single step (select the account to use), but
> integrating with each provider is often very time consuming.
>
> Keycloak manages a lot of the social flow, but it does not have a native
> experience and falls back to OAuth 2 web flow.  It is a bad user experience
> (and bad for user retention) if the first thing they do after they open
> your app they just downloaded if they are taken out of the app to sign into
> a website.
>
>
>> * What features/functions around authentication you should like to see in
>> Mobile.Next, both client and cloud side?
>>
>
> Better support for real time authentication events, asynchronous sessions,
> and WebSockets.
>
> On the client side we need support for Native platforms in a way that
> doesn't rely on WebViews.  We also need better exposure of best practices
> because the native platform gives us more options than the cookie store in
> a web browser does.  For instance tokens can be kept in a biometrically
> sealed keystore which require the user to use a thumbprint to unlock before
> the app can perform an operation.
>
>
>
>> * If you have used Keycloak before, what is your thoughts on integration
>> with it in mobile applications?
>>
>
> Keycloak is pure magical wonderfulness for Java EE Servers and web based
> applications.  Outside of this there is a lot of compatibility thanks to
> some smart design choices, but the documentation isn't great at explaining
> that.  Most of my googling for how to do something in KC often turns up my
> own blog posts ><.
>
> On Android KC is only OK.  It is really missing support for using the
> Google account found on most devices.  You can work around this by using
> webviews, redirects, etc to get this information but there isn't a golden
> scenario.
>
>
>> * Anything else around authentication?
>>
>
> I feel like we are 80% there already.  We need good docs and examples for
> non trivial integrations.  The learning curve is really steep because the
> problem is really complex and requires a lot of integrations.  If we can
> just support a few of those with sensible defaults that are easy to change
> then I think we can make a lot of headway.
>
>>
>> The answers to those questions will help us make sure we deliver
>> something that will solve the problems you are facing day to day.
>>
>> We look forward to your answers and thank you in advance.
>>
>> Regards,
>>
>> --
>>
>> WEI LI
>>
>> SENIOR SOFTWARE ENGINEER
>>
>> Red Hat Mobile <https://www.redhat.com/>
>>
>> weil at redhat.com    M: +353862393272
>> <https://red.ht/sig>
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> feedhenry-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170828/dcdba2fb/attachment.htm>