I know we are in "code freeze" mode, but removing (or just disabling!) an option shouldn't be very complex.
We have yet another OAuth 2 issue, this time with JHipster 4 / Angular 2 at #4982
Please note the subject here is just the OAuth2 option when generating a monolith. Using UAA + OAuth2 for microservices (which is still in beta) is a different option, and makes a lot more sense to me (as there is a separate OAuth2 server, and that's how most people should use it).
I would like to start a discussion to remove this option:
We are using OAuth2 from an Android frontend, but there's absolutely no problem in refactoring our code to use JWT instead. Anyway, thank you for asking :-)
"There is a security issue with it"
Should be removed then.
As long as the social login is still possible with Facebook, Twitter and Google login, I have no issues whatsoever to remove this option.
@notflorian yes social login is another option, it will remain (but it's currently broken with JHipster 4, so if you can help with #5002 that would be great - I'm not really good with that part)
On a monolith, using JWT is just easier and better, so I really don't see the point. And that's what everybody's doing according to our statistics.
If you're doing only authentication, yes, JWT is better. But Oauth2 is primarily for authorization and 3-legged auth which is a bit different. Eg. : a user can authorize a third party app to perform some actions on your server.
Then, I agree that using an external IAM such as UAA, Stormpath, WSO2, etc is better for the job. I think it's not the role of JHipster to provide complex IAM. However it should be easy to make JHipster work with these (through modules for instance)
I always feel bad about removing options. Can we externalize it to a module ?
Eventually, is the ng oauth2 issue also present with micro-service + UAA ?
As always, @cbornet you are of excellent advice! Indeed, this is a different use case than JWT, and I overlooked that.
Then, as you say, it would be logical that people use a third party provider:
I don't think issue #4982 is also present with UAA, but I don't know both options well enough.
OAuth 2 was an important factor for one large client I'm aware of. In fact Jhipster also gave my team a nice, easy to setup environment with which to experiment with this approach and show something tangible to management.
If its something easier to fix then I would like that rather than removing the option but if its very complex to fix then lets disable it
Correct @deepu105 -> if anyone wants to correct #4982 then we have no reason to remove this now, and thus we'll keep it.
Then, if people really want this option, please send us your statistics: if we have no statistics on an option, that's normal we will remove it at some point.
I know of atleast few real world jhipster apps using this option in my
previous company including a backend for some high profile samsung gear
watch apps used by a famous airport :P
Thanks & Regards,
Deepu
On Sun, Jan 29, 2017 at 7:43 PM, Julien Dubois notifications@github.com
wrote:
Correct @deepu105 https://github.com/deepu105 -> if anyone wants to
correct #4982 https://github.com/jhipster/generator-jhipster/issues/4982
then we have no reason to remove this now, and thus we'll keep it.
Then, if people really want this option, please send us your statistics:
if we have no statistics on an option, that's normal we will remove it at
some point.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/5010#issuecomment-275935868,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlFx1KpcLkyWH4W8G1yyGrzALiiOgqks5rXN20gaJpZM4LwzTG
.
@jdubois since the issue is fixed I think we can close this?
Oh i didn't follow that... OK then, first let's release JHipster 4, then we'll discuss about this!
FWIW, at Stormpath, we use JWTs for OAuth tokens - so it's somewhat of the best of both worlds.
Just from my own experience, I typically use session auth when doing demos and training of jhipster, because then I can show the social login features, which people like to see. However, for a 10MM project we started last year, we used OAuth2, because we wanted both stateless capabilities for scalability, and the integration with other tools that support OAuth 2 but not jwt. So when you note that generated projects only use Oauth2 0,6% of the time, that matches my own use of the tool. But, it's that OAuth2 project that is actually paying the bills :). So, personally, I would prefer if it were kept in. When the separate server option is out of beta, this becomes less important, but still useful for those projects that want to start with a simple monolith but still integrate with OAuth 2 gateways and providers.
I knew this was a bad idea: #5298
So, as I said, lots of maintenance work, for only 0,6% of projects... I'm definitely not spending my night on this :-(
It looks nice to have an UAA which handles OAuth2, and monoliths which could be able to consume it (token + Authz).
OAuth2 within a monolith is a non sens IMO.
How can we get the access tokens,what would be the url for that along with the client- secret id,Can you please Describe it.
Most helpful comment
"There is a security issue with it"
Should be removed then.