Deprecate custom JWT and Oauth2

[VinodAnandan]

Hi,

I am bringing this old discussion (#9120) back as it's relevant to the recent security issues (#10401) with Jhipster. The user Identity, Authentication, and Authorization are very security-sensitive functionalities and we should give priority to security.

OpenID Connect securely uses both Oauth2 and JWT to implement secure Identity and Access Management. The OIDC has already covered multiple countermeasures to prevent attack patterns. We shouldn't reinvent insecure IAM with custom JWT and Oauth2 implementation. We should learn from Facebook. Facebook had multiple bug bounty with custom Oauth2, even though they have improved eventually they got hacked because of it. https://nat.sakimura.org/2018/10/09/facebook-hack-and-oauth-user-authentication-2-min-oauth/

So please consider using OpenID Connect instead of custom JWT and Oauth2. OpenID Connect is a pre-vetted way to utilize secure federated IAM which includes Oauth2 and JWT. Open Banking depends on FAPI (extended version of OIDC) (  https://openid.net/2018/07/12/the-uk-open-banking-implementation-entity-adopts-the-openid-foundation-financial-grade-api-fapi-specification-certification-program/ ).

Even for the OpenID Connect integration, we have to be very careful as an insecure integration can also result in security issues. We have to use the OpenID foundation certified integrations wherever possible. If it's not available, we need to confirm the compliance with the standard by utilizing the test automation suite from the OpenID foundation.

https://openid.net/certification/
https://openid.net/certification/instructions/

If you need more information, please let me know.

@yelhouti , @mraible , @deepu105 , @avdev4j , @jdubois , @pascalgrimaud , @jhipster/developers
 
Thanks and Regards,

Vinod

[mraible]

We offer OIDC support, as implemented by Spring Security. Are you suggesting we remove all other authentication options?

…

On Sep 15, 2019, at 15:52, Vinod Anandan ***@***.***> wrote: Hi, I am bringing this old discussion (#9120) back as it's relevant to the recent security issues (#10401) with Jhipster. The user Identity, Authentication, and Authorization have very security-sensitive functionalities and we should give priority to it. OpenID Connect securely uses both Oauth2 and JWT to implement secure Identity and Access Management. The OIDC has already covered multiple countermeasures to prevent attack patterns. We shouldn't reinvent insecure IAM with custom JWT and Oauth2 implementation. We should learn from Facebook. Facebook had multiple bug bounty with custom Oauth2, even though they have improved eventually they got hacked because of it. https://nat.sakimura.org/2018/10/09/facebook-hack-and-oauth-user-authentication-2-min-oauth/ So please consider using OpenID Connect instead of custom JWT and Oauth2. OpenID Connect is a pre-vetted way to utilize secure federated IAM which includes Oauth2 and JWT. Open Banking depends on FAPI (extended version of OIDC) ( https://openid.net/2018/07/12/the-uk-open-banking-implementation-entity-adopts-the-openid-foundation-financial-grade-api-fapi-specification-certification-program/ ). Even for the OpenID Connect integration, we have to be very careful as an insecure integration can also result in security issues. We have to use the OpenID foundation certified integrations wherever possible. If it's not available, we need to confirm the compliance with the standard by utilizing the test automation suite from the OpenID foundation. https://openid.net/certification/ https://openid.net/certification/instructions/ If you need more information, please let me know. @yelhouti , @mraible , @deepu105 , @avdev4j , @jdubois , @pascalgrimaud , @jhipster/developers Thanks and Regards, Vinod — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[PierreBesson]

Hello everyone, remember that JHipster is a hobby community project of volunteers. We are not making money ! We don't employ anyone.
We never promised any security guarantees to our users or any guarantee of any kind. It is explicitly stated in the Apache 2 license that "this software is provided AS IS".

So I'm totally against removing the jwt option which is our most popular option. This would harm the project as it is more complex and require an external server setup (keycloak, okta,uaa). However I'm not against having a write up on our website to explain that oauth2 is the more secure option.

[Edit] sorry for accidentally closing this issue.

[pascalgrimaud]

I don't understand well this ticket. I think @VinodAnandan talks about our current implementation of OAuth2/OIDC, not about the JWT authentication.

Even for the OpenID Connect integration, we have to be very careful as an insecure integration can also result in security issues

Better than words, can you have a look at our code in generator-jhipster or here https://github.com/jhipster/jhipster-sample-app-oauth2
Then, can you point us the code your consider as unsecured, so we can discuss ?

[vishal423]

I am also not in favor of removing other authentication options. They are useful in different contexts. However, I feel that we can have OIDC authentication as default.

[mraible]

As you likely know, I'd love to see OIDC as the default. However, I believe it causes more developer friction. With JWT, there's no Docker containers you need to start. With OIDC, you need to start Keycloak. FWIW, I recently recorded a screencast about how to switch from JWT to OIDC in a JHipster app. I hope to publish it soon.

…

On Sep 16, 2019, at 00:13, Vishal Mahajan ***@***.***> wrote: I am also not in favor of removing other authentication options. They are useful in different contexts. However, I feel that we can have OIDC authentication as default. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[VinodAnandan]

My suggestion is based on a "Proactive Security" approach, rather than waiting for someone to find issues and then fix them. "Prevention is better than cure", I do believe that many use JHipster in production. My suggestion is to discourage custom JWT, Oauth2, and OIDC. It's always good to test custom OIDC with the test automation suite ( https://openid.net/certification/instructions/ ) I do understand JWT may enable easy bootstrapping, but using a free Okta, Oauth0, etc. developer account it's easy to set up an OIDC client. A non-production/test Keycloak server can be also used with static or dynamic client registration. An alternative proposal would be to have the dev/non-production and production profiles option while the application generation and the JWT option will only be active in dev/non-production' selection. I also like the idea to set OIDC as a default option. Please let me know your thoughts. On Mon, Sep 16, 2019 at 12:36 PM Matt Raible <notifications@github.com> wrote:

…

As you likely know, I'd love to see OIDC as the default. However, I believe it causes more developer friction. With JWT, there's no Docker containers you need to start. With OIDC, you need to start Keycloak. FWIW, I recently recorded a screencast about how to switch from JWT to OIDC in a JHipster app. I hope to publish it soon. > On Sep 16, 2019, at 00:13, Vishal Mahajan ***@***.***> wrote: > > I am also not in favor of removing other authentication options. They are useful in different contexts. However, I feel that we can have OIDC authentication as default. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10421?email_source=notifications&email_token=AHCPIEKD7SRJOZHOR43UOHDQJ5OUHA5CNFSM4IW4C5JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6YXI7A#issuecomment-531723388>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHCPIEIY6WMPXR35BUETHZDQJ5OUHANCNFSM4IW4C5JA> .

[pascalgrimaud]

We can't choose the options for our end-users. They are responsible for their choice and the code once if it's in production. The result would be the same if they coded it. So I think we'll stay with JWT by default.

Anyway, I don't understand what you mean here:

My suggestion is to discourage custom JWT, Oauth2, and OIDC

Then, I don't have answer for my question:

Better than words, can you have a look at our code in generator-jhipster or here https://github.com/jhipster/jhipster-sample-app-oauth2
Then, can you point us the code your consider as unsecured, so we can discuss ?

[pascalgrimaud]

I think it can be closed.
Feel free to add new comment to discuss if needed