[keycloak-user] Mobile Game Authentication Flow

[Mat Pataki]

Sure!
For IAPs, yes there is direct communication between our mobile clients and
our payment providers (apple, google, amazon, and facebook in our case),
however that's at a point well after we've established the user's identity.

Thanks again

On Tue, Feb 28, 2017 at 4:51 PM Bill Burke <bburke at redhat.com> wrote:

> 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> 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
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>