Closed poVoq closed 2 years ago
@poVoq,
I'm kind of in a similar boat with getting OAuth2 to work with Kanboard.
Thankfully the link you shared was a little bit helpful in getting me a little further (I don't think the older version of the Kanboard OAuth2 plugin had scopes yet when I first tried it out...the current one does seem to have it and with the notes about using the "/api/v1/user" scope in the link above it seemed to get me past the "scopes" error my IdP had been providing me with).
However, I'm still getting an "External authentication failed" error on each login attempt and the URL is redirecting back to my Kanboard install with something like this at the end of the URL: /oauth/callback?code=AC-NzNFOThDRDdBNjJDMkQ3MEYwMDMyNUQx&state=26d463d389f9e7bad2544fc681c31a2068f5d0e697196bbb42b3cd60359b
Not sure if you have any other tips to share, but I'm trying this plugin as well as the CAS Authentication plugin since I also can use that Single Sign On option, but in each case I seem to be running into difficulties.
Sorry, no idea. What OAuth2 provider are you using?
I guess much of this mess will be solved once OAuth2.1 released and more widely adopted.
It's a system that my workplace uses called PortalGuard (which supports CAS, SAML, and now OpenID Connect, which is where the OAuth2 support comes in that I was trying out initially last year, and then re-attempted again yesterday evening).
I think in both cases (for my CAS and OAuth2 tests yesterday) the main difficulty seems to be understanding what Kanboard is receiving information-wise, and what's it's doing (and running into a problem with) after that, even though the logs on the PortalGuard side seems like it's passing the correct information back to the application.
I actually thought the CAS option would be more straightforward (since it typically is setup-wise, since there's not as much back and forth with that protocol I feel), but even that one proved to be a bit troublesome, so I'm going to make a fresh attempt this morning to see if I can figure out a solution, starting with a fresh Kanboard installation and see if there's any improvement in how these two SSO options behave).
If I learn anything, I'll share some info here with what I find out.
So I went ahead and created a fresh Kanboard installation to test out the OAuth2 plugin once more to rule out an issue with our existing database.
With this test, I was actually able to login successfully.
The main difference I could note (since we're already using LDAP authentication) is that the oauth2_user_id value was set properly in the fresh installation (versus it doesn't seem to be added in correctly for our existing Kanboard installation).
At the moment, I'm not sure if this is by design of the OAuth2 Plugin or not, but it definitely seems like it would be an issue for anyone transitioning from LDAP Authentication (and has existing users already in their Kanboard database) to OAuth2 Authentication.
I was able to confirm that the missing oauth2_user_id value was the issue on the fresh installation since after the login was successful, and the only difference was the oauth2_user_id value being populated, I removed it and tried logging in again and ended up seeing this notice on the page (I wasn't seeing this with the Moon template I've been using for Kanboard, but it was shown on the fresh installation):
Notice: Undefined index: id in app\Core\User\UserProfile.php line 55
Along with the "External Authentication Failed" message that I had been seeing before (but which wasn't detailed enough to actually let me know what the issue was for our live Kanboard installation yesterday).
So I'll probably ask this question or create an issue about it here in the repository to see if there's a reason why the oauth2_user_id value can't be populated if it isn't already set when somebody first tries to login using OAuth2.
Another note is that since I still have LDAP Authentication enabled, I can currently use either option to authenticate so they can both work at the same time (however, since the LDAP Authentication option wouldn't populate the oauth2_user_id value it could cause an issue for new users if they were to use LDAP first and then OAuth2...in any case it probably won't be much of an issue for us as I'm planning to fully transition us to using OAuth2 in this case, but just felt it was worth noting).
Lastly, the OAuth2 plugin doesn't appear to result in any Role changes after login the same way the LDAP one can if the configuration settings are set, so if a user is an Admin before using OAuth2, they should still be an Admin after they login using OAuth2 (meaning that Role assignment would be managed more directly within Kanboard, which I'm actually ok with since we have relatively few folks that would even have the Admin Role assigned).
For example I managed to get it fully working with my own Gitea instance*, but the setup was far from obvious, so some templates where you can just add in your self-hosted domain would be very useful.
See: https://github.com/go-gitea/gitea/issues/8004