Re: [keycloak-dev] Keycloak and mobile

On 14/08/13 05:24 PM, Bill Burke wrote: 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. 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 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. 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.