[keycloak-user] Mobile Game Authentication Flow

[Bill Burke]

I don't think a registration back end would be that hard to do for you.  
I'd be curious to know how in-app purchases would work. Isn't that 
something you have to go through Apple to do if on iphone?  I have no 
idea about Android.  Maybe that's a service you could leverage for 
authentication and identity.  Seems like an interesting problem.  Get 
back to us on what you decide to do please!


On 2/28/17 4:05 PM, Mat Pataki wrote:
> Thanks Bill, this is really helpful.
>
> I suspected that I've have to write something custom for this purpose, 
> but it's good to know that I've not just missed something obvious.
>
> There are some pretty strong business reasons to keep our users in our 
> app during authentication, and in particular during the initial user 
> registration, reasons that I don't think are specific to my company, 
> but to mobile games generally. Although I can understand KeyCloak's 
> opinion about using the mobile browser for this purpose, this is very 
> likely a sticking point for many mobile game studios, but I digress.
>
> Thanks again for the speedy response!
>
> Mat
>
>
>
> On Tue, Feb 28, 2017 at 3:43 PM Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     You want users to be able to login through a social provider?  We
>     don't
>     have a REST-based social login abstraction.  Its all browser based.
>     Keycloak delegates authentication to social providers. One big problem
>     is that not all social providers are necessarily password only.
>     Depending on the user they might require an OTP or code sent by SMS.
>     So, unless the provider has some kind of challenge response REST
>     API, we
>     wouldn't know what to prompt for credentials.
>
>     For registration you're going to have to write some custom backend
>     that
>     sits between your mobile app and Keycloak.  Right now, we don't have a
>     REST api for unauthenticated user registration.  We also don't
>     have fine
>     grain roles so you can say a particular user account is allowed to
>     register new users.
>
>     For mobile, we were hoping that apps would do mobile redirects to the
>     phone's browser. Our web pages are completely themable and
>     customizable
>     so that you could brand them to your company.
>
>
>     On 2/28/17 2:06 PM, Mat Pataki wrote:
>     > Hello!
>     >
>     > I'm a developer at a mobile gaming company, and I'm trying to better
>     > understand how/if KeyCloak fits within the paradigm that we
>     have, and that
>     > I believe also to be pretty typical in this space. At the moment
>     I am
>     > specifically interested in User Registration and Authentication.
>     I should
>     > say that I've spent a larger amount of time with the
>     documentation before
>     > turning here, so hopefully I'm not missing something completely
>     obvious
>     > (although I can't really rule that out!).
>     >
>     > Third party identity providers such as facebook and google
>     provide mobile
>     > SDKs that are capable of completing the OAuth2 flow with their
>     respective
>     > identity platforms. In the end, our consuming mobile apps
>     receive an access
>     > token if all goes well. We send this token to our current custom
>     backend
>     > authentication solution which will validate them, obtain an ID
>     from the
>     > identity provider, and link that ID to our own internal ID for
>     the user.
>     > It's this backend component that I would like to replace with
>     KeyCloak.
>     >
>     > For reference, I see very similar code to this in the KeyCloak
>     source, here
>     >
>     <https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/social/facebook/FacebookIdentityProvider.java>,
>     > which is encouraging!
>     >
>     > The problem however, is that KC's social login flow, and
>     seemingly the
>     > custom SPI flows as well, all begin with the web based
>     registration page.
>     > For our use case, we would like to avoid directing our users
>     away from our
>     > app during this process, and in fact avoid performing the OAuth2
>     flow
>     > between us and facebook, for example, entirely. This is
>     something we have
>     > today via these client SDKs.
>     >
>     > Down the line we plan to use KeyCloak for it's more traditional
>     use cases,
>     > including securing our own micro serves and applications, but that's
>     > assuming that we can solve this problem.
>     >
>     > Any advice would be greatly appreciated! Thanks in advance!
>     >
>     > Mat
>     > _______________________________________________
>     > keycloak-user mailing list
>     > keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>