Seems like that there is very little documentation on the new Oauth2 client authentication. The only thing I could find is this short announcement:
I have found the section under Admin->security that lets you create new client identifiers and secrets. It seems to work fine, but the question is now how to actually utilize them.
In my case I am trying to authenticate a DokuWiki instance against my NC12 user database. There is a OAuth2 plugin for Dokuwiki that allows custom providers, see: https://www.dokuwiki.org/plugin:oauth
When I install that DW plugin it gives me the “redirect URL” that I need to create a new client identifier & secret. However in the DW plugin settings it asks for four items:
“Application/Client ID” which I assume is the same as “Client identifier” in NC12?
“Secret” which is the same in NC12
“authorization endpoint URL” which should be some url on my NC12 instance?
“access token endpoint URL” which should be some url on my NC12 instance?
So those last two settings would be interesting to know. Any other tips how to set it up are also appreciated as I am pretty new to this.
Interesting would be also what kind of user data identifiers I could write into the plugin so that groups and other profile details are also retrieved from NC12 via OAuth2.
Hi there, I wanted to know if you could elaborate on your configuration steps and all of the URLs that you had to use to get this to work…
Right now I am using an empty GitLab install as an oauth provider but I would like to authenticate against my NextCloud user base instead. I am using an Nginx server and currently using the bitly oauth2 proxy to accomplish this.
I also find it odd that there is zero mention of the oauth support that is now built in. There is no mention in any docs or any forums other than this that I can find.
I have not really gotten this to work… well sort of… not sure to be honest
I have been trying to authenticate against it with a Dokuwiki plugin, but I suspect this plugin is not working as I think it is. Anyways, on the Nextcloud side of things everything seemed to work as the Dokuwiki redirected to Nextcloud with a big “grant” button upon which it redirects back to the Dokuwiki (where then things don’t work further).
All I had to do was to create an ID and secret (with the dokuwiki redirection URL) under the security settings and include these in the Dokuwiki plugin together with the two URLs above.
However after this rather futile effort I started looking for other means to do something similar as it seems OAuth2 is not really meant to do this kind of SSO anyways, see:
Thanks for the feedback. Yea I have found the distinctions between the two, we are really just trying to use this a a quick and dirty login screen. Its for sure not the cleanest or most acceptable way but it beats being open to the world!
My biggest issue right now is that I cant seem to find an oauth proxy server that will support NextCloud.
Let me know if you get anywhere with this and I will do the same.
Hmm, I played around with another application and again I get to the point where it redirects from Nextcloud, but then the other website is complaining that no “user id” was found.
I guess that could have something to do with that other OAuth2 providers also have a “user URL” next to the above authorization and token URLs. I left that blank in the other site’s setting as I have no idea what to put in for Nextcloud. Edit: looking at the routes.php file in the oauth2 app it seems no such thing exists.
Also Nextcloud’s oAuth2 is currently missing “scopes”, but I guess that should not be the show-stopper here.
When I add the index.php to the authorize and token URL it seems to work a lot further but ultimately also results in a: Internal Error: Action not implemented
upon redirection to Kanboard. Looks more like an Kanboard issue though?