-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade Spring Security's OIDC Support #9276
Comments
@mraible this implementation (as well as the current one) has security issues, please let's fix them before moving forward. |
@yelhouti Please provide a pull request to my PR’s branch with your suggested changes. I’ll be happy to review your fixes. Saying there’s issues without providing a fix doesn’t help me. |
Sorry @mraible I forgot to delete this comment, and in order to put everything in the long issue we already have.
Step two 2 (and 3) clearly mention that after decryptin and signature verification the SP MUST verify the audience field... |
Do you think Spring Security should handle this? It seems strange to push this validation onto a developer using Spring Security.
… On Feb 17, 2019, at 10:22, yelhouti ***@***.***> wrote:
Sorry @mraible I forgot to delete this comment, and in order to put everything in the long issue we already have.
The main issue here is that OIdC is used the some way you would with OAuth2 Authorization flow, on the other hand the spec clearly says that after validating the token the same way you would with OAuth2 (step 1) you MUST:
1- Follow the validation rules in RFC 6749, especially those in Sections 5.1 and 10.12.
2- Follow the ID Token validation rules in Section 3.1.3.7.
3- Follow the Access Token validation rules in Section 3.1.3.8.
Step two 2 (and 3) clearly mention that after decryptin and signature verification the SP MUST verify the audience field...
I could argue with you that this is not that necessary because the token is retrieved with a private (not public) client, this why this approach might also be secure, but the spec is the spec and we should follow it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
We could use the Okta Spring Boot starter. AFAIK, it does audience validation.
… On Feb 17, 2019, at 10:22, yelhouti ***@***.***> wrote:
Sorry @mraible I forgot to delete this comment, and in order to put everything in the long issue we already have.
The main issue here is that OIdC is used the some way you would with OAuth2 Authorization flow, on the other hand the spec clearly says that after validating the token the same way you would with OAuth2 (step 1) you MUST:
1- Follow the validation rules in RFC 6749, especially those in Sections 5.1 and 10.12.
2- Follow the ID Token validation rules in Section 3.1.3.7.
3- Follow the Access Token validation rules in Section 3.1.3.8.
Step two 2 (and 3) clearly mention that after decryptin and signature verification the SP MUST verify the audience field...
I could argue with you that this is not that necessary because the token is retrieved with a private (not public) client, this why this approach might also be secure, but the spec is the spec and we should follow it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Are you sure audience validation is necessary when using oauth2Login()? This issue, and your example code, only seems to apply to resource servers. spring-projects/spring-security#5226 JHipster doesn’t ship with a resource server by default. I’m happy to try it, just not sure that it’ll be used. |
@mraible you are right this won't be used if added to your code since your are using the authorization flow with a private client and therefore (as I said earlier) one could say that there is now need to check the
|
The Example: An attacker reused the Facebook video uploader token for Facebook mobile application. |
@VinodAnandan is right, but it mainly protects against malicious clients using token their received from user in other clients. This is why OAuth2 (not OIdC) should never be used for authentication. But in our case since we use the Auth flow and tokens are received directly from the IdP after checking the client's credentials I don't see hoe the same attack can apply. But again, the spec is the spec and we must follow it. |
Each and every attributes in the spec has its own importance. The great authors of the spec already considered many security use cases. |
I don't believe it's necessary to validate the audience when using If you do want to setup a resource server in JHipster, see Spring Security's resource server docs:
security:
oauth2:
resourceserver:
jwt:
issuer-uri: https://idp.example.com
The aforementioned docs have more information on the validation process. So it looks like Spring Security handles validating incoming JWTs (when setting up a resource server). If you want to make this more robust, you can include audience validation like Okta does:
The reactive side of things is very similar. Since JHipster doesn't define a resource server by default (for monoliths), this extra configuration makes no sense. Microservices might need it, but I haven't implemented that yet. For modules that create resource servers (JHipster Ignite and Ionic for JHipster), I believe it's up to those projects to implement the resource server properly. Luckily, @ruddell and myself are the leads for those projects, so we'll do our best to do it right. |
@mraible I might agree with you that may be audience validation (and even signature validation) is not necessary in your scenario since the introspection is done by the IdP, the client is verified by the IdP before giving the token since the client is private communication is done through SSL with hopefully certificate pining. |
The implementation I'm working on right now only pertains to monoliths and microservices with OAuth 2.0 / OIDC for authentication. If I encounter a resource server as part of that, I'll go ahead and implement audience validation. I'm not concerned about UAA. I did not code that part of JHipster, nor do I maintain it. I believe @ruddell does. |
Actually @xetys maintains the UAA code, I just help out anywhere I can. |
POC for microservices created at mraible/jhipster-ms-oidc-improved#1 |
Integration in generator provided by #9416. |
This work has been completed in JHipster. Ionic for JHipster and Ignite JHipster still need to update their OIDC implementations for JHipster 6. |
Overview of the feature request
Spring Security 5.1 and (native with Spring Boot 2.1) has a new way to configure OAuth 2.0 Login. Rather than using
@EnableOAuth2Ssso
, it's a regular part of the web security configuration. This issue is to track that upgrade progress.Motivation for or Use Case
Using
@EnableOAuth2Sso
and@EnableResourceServer
is no longer recommended in Spring Boot 2.1. The reasons for the change can be found in Josh Long's Bootiful Podcast, published on Jan 25, 2019. It's an interview with Madhura Bhave and the discussion starts at 21:30.The pull request below shows the changes necessary to modify a v5.8.1 monolith with defaults + OAuth 2.0 for authentication. Please have a look and let me know if you see any issues.
mraible/jhipster-oidc-improved#1
Known Issues
OAuth2AuthenticationToken
, but not in its principal.The text was updated successfully, but these errors were encountered: