Hello.
I managed to include Keycloak logout support in my company. What I did was copy the following files:
So basically I used the same CustomTab/Browser authorization mechanism but for logout. I'm aware open id connect logout is still a draft. However it seemed to me that the code is not generic enough to allow "CustomTab commands" other than login.
What I want to know is if this is correct and if it's not what can I do to avoid copy/paste?
I am trying to understand the goal.
Are you trying to trigger SLO from the App to logout the web applications.
We haven't really talked about that with respect to front channel logout.
I don't know if the other apps on the device would be able to pick up the logout via the receiver.
How did this work for you?
This is likely something we will need to discuss in the OpenID Connect working group.
Yes the idea is to have SLO from the App to logout the web applications (or vice-versa). We have a working solution with Keycloak as the server (which implements logout). From our tests, the different applications do pick up the logout. We did nothing special, only used the same "CustomTab + Receiver" exactly like it is done with authorization. Perhaps this is obvious, but it doesn't work with a simple HTTP client, it must be done with the "CustomTab + Receiver". In other words the logout opens a browser that calls the logout URL and gets back to the application when it's done.
More specifically:
Sure I understand you would have to discuss with OpenID Connect working group as it doesn't seem to be part of the standard yet. It would be nice to have a generic way to call these "CustomTab/Receiver" solution though.
If there are more use cases for user-mediated actions, then is makes sense to try and generalize the tab-and-receiver pattern for reuse. Until now, there was only the authorization flow, so logout sounds like a good second use case, though I'm hesitant to add implementations of draft standards to the core library. This may be better served as an "extension" library, until front-channel logout is more mature, at which point we can merge it into the main library.
The current receiver is fairly simple and most of the code is oriented around translating the response into the appropriate model type. It is unclear to me at present whether it would be cleaner to just have a separate receiver for each type of response, or use one receiver as a router for per-response-type handling. @unit73e - could you send me your changes for logout support as a patch or pull request, so I can see what the similarities and differences are?
@iainmcgin yes but I will have to remove some parts of the code that we added specific for our own demo. I'll make sure to send our modifications this week as well as the steps for testing.
Finished the pull request. The LOGOUT_TEST_SETUP.md is quick guide to test the logout with keycloak.
Hello, We have also implemented Logout functionality in a similar manner. It would be nice to get logout support from the library. My other comment is that when logout fails (ie. logout has already been performed by another app), the browser never calls the redirect URI, but only show the "invalid grant" text. Do you know of a soluition for this problem?
Hello. Can someone share logout changes?
@llOldmenll
These are the changes made by unit73e two years ago:
https://github.com/unit73e/AppAuth-Android/commit/c56c9e14854b1c7df7a2fdf9353ad67c3ae0eaf2
See #374 for what we are planning to do to support logout and other related actions generically. We had avoided this in the past as IDPs all seem to do this differently, and we didn't want to integrate one particular approach over the others into the core library.
Closing this as logout is available in the library since 0.8.0 and has been tested with Keycloak.
Most helpful comment
See #374 for what we are planning to do to support logout and other related actions generically. We had avoided this in the past as IDPs all seem to do this differently, and we didn't want to integrate one particular approach over the others into the core library.