On Wed 14 Aug 2013 03:14:41 PM EDT, Bill Burke wrote: 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). The way google handles it is either the localhost redirect or using a special urn as the redirect (urn:ietf:wg:oauth:2.0:oob) and making the token the page title. I had a simple hacked up prototype which returned a token as part of a a redirect urn (urn:foo:bar:token:123456789) and a custom webview would look for the value. I don't see the value in redirecting between applications using urls like this though, handling it within one webview seem to make more sense to me. Can you explain what use case that would be?

On Wed 14 Aug 2013 04:27:12 PM EDT, Bill Burke wrote: 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. 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.

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.