Conversation
|
@arvindkrishnakumar-okta @mraible initial support for auth0 hosted login. I also updated the implementation to lookup the well-known metadata instead of hard coded values (with hard coded values as backup) @arvindkrishnakumar-okta can you please review? I left some TODO comments in code, would appreciate your input on it |
oauth2/src/main/java/com/okta/spring/boot/oauth/env/OIDCMetadata.java
Outdated
Show resolved
Hide resolved
...java/com/okta/spring/boot/oauth/env/OktaOAuth2PropertiesMappingEnvironmentPostProcessor.java
Outdated
Show resolved
Hide resolved
...java/com/okta/spring/boot/oauth/env/OktaOAuth2PropertiesMappingEnvironmentPostProcessor.java
Show resolved
Hide resolved
...java/com/okta/spring/boot/oauth/env/OktaOAuth2PropertiesMappingEnvironmentPostProcessor.java
Outdated
Show resolved
Hide resolved
|
I tried checking out this branch and using it with okta-samples/okta-spring-boot-sample. Steps I used:
I received an error on startup: This seems to be related to spring-dotenv, so I removed it and put the values directly in I started again, opened my browser to I added this URL to my Auth0 app's callback URLs and refreshed my browser. This time, it worked! I'm able to see all my claims on the profile page.
One question: is the I noticed the logout doesn't work. This is probably because Auth0 doesn't have an I also tried to access the Spring Boot app as a resource server. I created an access token using the Auth0 CLI. I set the access token as a Then, used HTTPie to try and access the This results in an error: Since Auth0 only returns a JWT when you specify a valid audience, I added my audience to I restarted and tried again. I get the same error. |
This reverts commit e4de5d4.
|
I updated the impl to use opaque tokens only for Okta domains. Now for AS I'm able to get past the issue @mraible had since auth0 domains now use JWT mode. But now there is an NPE from spring security, probably some issue within the UserUtil, I'll do some debugging, in the meantime @arvindkrishnakumar-okta any pointers? Here is the trace |
|
@deepu105 I'm guessing, the OidcUser info returned in Auth0's OIDC metadata doesn't contain/map to the necessary OIDC user info required by Spring Sec's internal mapping. |
|
@deepu105 I believe this is expected and there might be a bug in the okta-spring-boot-sample. The error comes from this line. When you log in with Spring Security's If I try I fixed the sample in okta-samples/okta-spring-boot-sample@3311fb6. |
|
Oh ok that makes sense, I never paid attention to the sample itself since I
assumed it works without issues with Okta. I'll verify it tomorrow
…On Mon, 27 Feb, 2023, 11:48 pm Matt Raible, ***@***.***> wrote:
@deepu105 <https://github.com/deepu105> I believe this is expected and
there might be a bug in the okta-spring-boot-sample
<https://oktainc.atlassian.net/browse/OKTA-spring-boot-sample>. The error
comes from this line
<https://github.com/okta-samples/okta-spring-boot-sample/blob/main/src/main/java/com/example/sample/Application.java#L47>.
When you log in with Spring Security's oauth2Login(), you can use @AuthenticationPrincipal
OidcUser oidcUser in a method signature and it will work. However, if
you're accessing the method with a JWT (and the Spring Boot app is acting
as a resource server), this will not resolve. You have to use Principal
in the arguments or @AuthenticationPrincipal Jwt jwt.
If I try http :8080/hello "Authorization: Bearer $TOKEN on the
okta-spring-boot-sample
<https://oktainc.atlassian.net/browse/OKTA-spring-boot-sample> with Okta,
it fails too:
{
"error": "Internal Server Error",
"message": "Cannot invoke \"org.springframework.security.oauth2.core.oidc.user.OidcUser.getFullName()\" because \"oidcUser\" is null",
"path": "/hello",
...
}
I fixed the sample in ***@***.***
<okta-samples/okta-spring-boot-sample@3311fb6>
.
—
Reply to this email directly, view it on GitHub
<#547 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIOKF56JLKVSSL3DQ6V3FTWZUVLFANCNFSM6AAAAAAVCZ2FD4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@mraible it works with your fix on the sample app |
| issuer += "/"; | ||
| } | ||
| ResponseEntity<String> response | ||
| = restTemplate.getForEntity(issuer + ".well-known/openid-configuration", String.class); |
There was a problem hiding this comment.
Does this lookup happen on startup? When I was working on my native Java examples post, I discovered that Spring Security did a metadata lookup on startup. I convinced them they should do it on the first request instead, so the startup time would be faster. It'd be unfortunate if this reverted the default Spring Security behavior.
The best way to test this is likely to create two different Spring Boot apps. One uses the Okta Spring Boot starter and one uses raw Spring Security. Compile them both to native images. Then compare startup times.
|
@arvindkrishnakumar-okta do you think we can merge this and make a release. I can then write a blog post showing how to use this with auth0 |
|
I just tried this again and can confirm that both login and access the I also remembered this sample has a Unfortunately, when I configure this sample for Okta with To see if this happens with Spring MVC, I tried the sample's This seems to indicate It seems that Okta works fine now. However, there's an issue with WebFlux. |
|
@mraible do you think the webflux issue is a blocker to merge this PR? |
|
I've done some testing of this PR, nice work! Using the okta-spring-boot-sample I also verified that login/logout with a Servlet application works (from comments looks like there is an issue with WebFlux login unrelated to this PR). I also tested this change with a resource server app. I was able to secure endpoints including only allowing access based on scopes present in the JWT. One thing that isn't accounted for here is being able to use the I don't think it needs to be part of this PR, but at some point this starter should extract authorities from the |
|
Nice findings @jimmyjames can you open an issue to track the permission issue |
|
@mraible, this is interesting, I'm seeing the same thing when trying to update the Auth0 WebFlux sample for Spring Boot 3. Since that sample does not use this starter (just uses Spring directly), seems something might be wrong with WebFlux itself in this scenario, or we're missing some required changes.
|
|
@jimmyjames That's good to know. Can you please enter an issue in Spring Security's issue tracker? https://github.com/spring-projects/spring-security/issues If you don't have time, let me know and I can do it. They typically like a reproducible example. |
|
@mraible I think I discovered the issue; looks like redirect URIs with /**
* This filter ensures that the loopback IP <code>127.0.0.1</code> is used to access the
* application so that the sample works correctly, due to the fact that redirect URIs with
* "localhost" are rejected by the Spring Authorization Server, because the OAuth 2.1
* draft specification states:
*
* <pre>
* While redirect URIs using localhost (i.e.,
* "http://localhost:{port}/{path}") function similarly to loopback IP
* redirects described in Section 10.3.3, the use of "localhost" is NOT
* RECOMMENDED.
* </pre>I'll try it out and see if it works and follow-up. |
It does work, consider something similar for #554 |
|
@jimmyjames I tried adding that filter to the okta-spring-boot-sample's |
|
I created a PR to update the okta-samples/okta-spring-boot-sample#75 The I also tested this PR with Auth0 and everything works but the logout (likely because there's no |
|
That is correct. Excellent work, @deepu105! 😃 |
5 participants
Initial support for Auth0 hosted login fix #358