8:12 p.m.
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> 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