Hi there, I would like to pick up an old issue: KEYCLOAK-2606<https://issues. jboss.org/browse/KEYCLOAK-2606> Our current app uses Keycloak with the Cordova In-App-Browser. Technically this works fine, but the user experience is … uhmm … awful. The page renders quiet slow and has focus issues. I’d love to help getting some support for the browser-tab. I started porting the ionic sample app to browertabs, but would like to check back with you before doing something stupid. The idea is: 1. In Keycloak.js Cordova Adapter check if browertab is supported, else fall back to in-app-browser 2. Open the login-page with the In-App-Browser (leaving the app) 3. Register a custom-url-scheme and configure it as redirect url (i.e. keycloakapp://). We’ll need another Cordova plugin for this (i.e. deep links). The Cordova-Adapter needs to get extended for this, since „localost“ seems to be hardcoded as redirect-url) 4. The Keycloak-server will redirect to the app after login succeeded. The App will need to reinitialize the Keycloak-Adapter with the code given in the url - I’m not sure if this will work out of the box. Does this sound reasonable? Thanks, Gregor! _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hey Stian, Thanks, I took a good look at most of the libraries out there - but I still would love to continue using Keycloak.js.

I got quiet far pretty fast by implementing a second Cordova adapter ("Cordova-native“) and falling back to the old one it the required plugin is missing. Or would you prefer extending the existing Cordova adapter? That would make the code a little messy, since we would need a huge if in every method.

Figuring out the callback wasn’t to hard either - now the last missing piece is parsing the callback. Here we have the option of registering a universal link inside the Keycloak adapter which opens the app, or leaving this to the developer and provide a public method for it (like processCallback). I’m not quiet sure on these options, what are your thoughts on this?

- Gregor Am 29.05.2018 um 09:33 schrieb Stian Thorgersen <sthorger(a)redhat.com&gt;: Sounds reasonable. I recommend looking at the following first though before you start implementation AppAuth [1] and OAuth 2.0 for Native Apps [2] [1] https://appauth.io/ [2] https://tools.ietf.org/html/rfc8252 On 28 May 2018 at 16:34, Gregor Tudan <Gregor.Tudan(a)cofinpro.de&gt; wrote: > Hi there, > > I would like to pick up an old issue: KEYCLOAK-2606<https://issues.j > boss.org/browse/KEYCLOAK-2606> > Our current app uses Keycloak with the Cordova In-App-Browser. > Technically this works fine, but the user experience is … uhmm … awful. The > page renders quiet slow and has focus issues. > > I’d love to help getting some support for the browser-tab. I started > porting the ionic sample app to browertabs, but would like to check back > with you before doing something stupid. > > The idea is: > 1. In Keycloak.js Cordova Adapter check if browertab is supported, else > fall back to in-app-browser > 2. Open the login-page with the In-App-Browser (leaving the app) > 3. Register a custom-url-scheme and configure it as redirect url (i.e. > keycloakapp://). We’ll need another Cordova plugin for this (i.e. deep > links). The Cordova-Adapter needs to get extended for this, since > „localost“ seems to be hardcoded as redirect-url) > 4. The Keycloak-server will redirect to the app after login succeeded. > The App will need to reinitialize the Keycloak-Adapter with the code given > in the url - I’m not sure if this will work out of the box. > > Does this sound reasonable? > > Thanks, > Gregor! > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

> Figuring out the callback wasn’t to hard either - now the last missing > piece is parsing the callback. Here we have the option of registering a > universal link inside the Keycloak adapter which opens the app, or leaving > this to the developer and provide a public method for it (like > processCallback). > > I’m not quiet sure on these options, what are your thoughts on this? > Could you elaborate a bit on this please? Sure - The way those native browser tabs work is that the app requests to open a site, but has no access to what happens inside the browser. After the login is done, the browser redirects back into the app by using universal links. These URLs have be registered in the app, so the browser knows that it should pass those requests back. From there, we can get the oauth params (state and code) and fetch the token. The question is: should we implement this kind of callback logic inside the adapter, or should we provide the user a method for completing the login process upon redirecting? If we do this in the adapter, we would need to make some assumptions on the Cordova-Plugin being used and how the link is set up. I don’t think that’s a bad thing, but we would need to document how to setup the app so that the redirect works. This would also fit nicely in the current API of the adapter. The other option would be to leave it up to the user to handle the redirect and offer a callback for finishing the authorization. This would basically boil down to a method that takes the code and the state params (like processCallback in the current adapter). This would kind of break the API of the adapter, as the login method will behave differently for this native adapter. To summarize: doing more stuff in the adapter would simplify things for the developer, but might not work for existing apps - i.e. if they use a different plugin for handling universal links. I suggest starting with first option (handling redirects in the adapter) to get started - universal links don’t seem to be to widely used, so most apps shouldn’t run into problems with us picking a plugin for them. Maybe we can add another option to the adapter for manual redirect-handling later on.

Hi Stian, I’ve created a first version and submitted it as pull-request, so we can review it. https://github.com/keycloak/keycloak/pull/5256 It relies on the following plugins: - browsertab: https://github.com/google/cordova-plugin-browsertab - universal-links: https://github.com/nordnet/cordova-universal-links-plugin While the first works really well, the second is a bit of mess and looks abandoned. Sadly, it is still the best plugin for deep-linking into apps around if you don’t want to add branch.io as third party service. It still works, but the future of the plugin is unclear. Other plugins only provide custom-url-stlye links, which are deprecated since iOS 9. Sadly Universal-Links are not without problems either (at least on iOS), as they don’t really work with redirects: i.e. clicking on the login-button in the form takes you straight to the app, but hitting the „open“ button on the keyboard won’t - this is a problem which all oauth libraries are facing, so I guess there isn’t much we can do about it: https://www.google.com/search?q=universal+links+redirect+site%3Aforums.de... <https://www.google.com/search?q=universal+links+redirect+site:forums.deve... I have to do some more testing to see how well this works on Android. The first attempts looked promising. - Gregor Am 05.06.2018 um 20:12 schrieb Stian Thorgersen <sthorger(a)redhat.com&gt;: Sorry for the late response, but the first approach seems good to me. I would assume the app developer would have to configure the universal link for the app, but also configure it in the Keycloak adapter right so it knows what URL to handle? Or can it just handle it without knowing the exact link? I would assume changes needed to apps to switch between the "old mode" and the new mode with system browsers in either case so not to worried if it requires some changes for existing users. On 30 May 2018 at 10:26, Gregor Tudan <Gregor.Tudan(a)cofinpro.de&gt; wrote: > > >> Figuring out the callback wasn’t to hard either - now the last missing >> piece is parsing the callback. Here we have the option of registering a >> universal link inside the Keycloak adapter which opens the app, or leaving >> this to the developer and provide a public method for it (like >> processCallback). >> >> I’m not quiet sure on these options, what are your thoughts on this? >> > > Could you elaborate a bit on this please? > > > Sure - The way those native browser tabs work is that the app requests to > open a site, but has no access to what happens inside the browser. After > the login is done, the browser redirects back into the app by using > universal links. These URLs have be registered in the app, so the browser > knows that it should pass those requests back. From there, we can get the > oauth params (state and code) and fetch the token. > > The question is: should we implement this kind of callback logic inside > the adapter, or should we provide the user a method for completing the > login process upon redirecting? > > If we do this in the adapter, we would need to make some assumptions on > the Cordova-Plugin being used and how the link is set up. I don’t think > that’s a bad thing, but we would need to document how to setup the app so > that the redirect works. This would also fit nicely in the current API of > the adapter. > > The other option would be to leave it up to the user to handle the > redirect and offer a callback for finishing the authorization. This would > basically boil down to a method that takes the code and the state params > (like processCallback in the current adapter). This would kind of break the > API of the adapter, as the login method will behave differently for this > native adapter. > > To summarize: doing more stuff in the adapter would simplify things for > the developer, but might not work for existing apps - i.e. if they use a > different plugin for handling universal links. > > I suggest starting with first option (handling redirects in the adapter) > to get started - universal links don’t seem to be to widely used, so most > apps shouldn’t run into problems with us picking a plugin for them. Maybe > we can add another option to the adapter for manual redirect-handling later > on. > For the first approach I assume the app developer would have to pick a