Is it possible to supply a valid oAuth token (Github, Twitter, Auth0) to Horizon via the client? I'm asking this because we use Auth0 as provider. We have a web client and react native app and would like to use the custom extra signup fields from Auth0. Currently there is no way to use this with Horizon right?
It would be easier on react-native to use something like https://github.com/auth0/react-native-lock to prevent the need for a WebView, regex etc.
Is it possible to communicate with auth0 from the client directly, then receive a valid auth0 token and then supply this token to Horizon server so that the Horizon server knows the user is authenticated? Or is there any other way to get the custom signup fields working and prevent the usage of a Webview with redirect URL on react native?
Thanks!
We talked about something like this, I think the consensus is that this isn't really the horizon client's job, the web app should make ajax requests to Auth0 itself.
That being said, we haven't decided where storing the oauth token should go. Right now that auth information is lost. I think we should store it provider table and make it available on the user object, but there's an argument to be made that this could just be its own plugin.
Yes, sorry wasn't very clear, I also meant that the developer should be able to write custom JS code on the client to request a token with Auth0 or Github or .. and then supply this token to the horizon backend somehow. Because now Horizon server communicates with the oauth provider to request a token right?
In addition to what @arthurvi is saying, this is needed in order to use something like https://github.com/auth0/lock-passwordless. It would also make it easier to work around the issues with the current auth/user system until the plugin api is released.
Is it ok to add an extra endpoint to https://github.com/rethinkdb/horizon/blob/next/server/src/auth/auth0.js
where we can supply an idToken or accessToken instead of an Authorization Code Grant?
Most helpful comment
In addition to what @arthurvi is saying, this is needed in order to use something like https://github.com/auth0/lock-passwordless. It would also make it easier to work around the issues with the current auth/user system until the plugin api is released.