Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Omid Dehghan
    @odchan1_twitter
    In case anyone was interested in the problem above, the problem was about the way I set the action of the form page.
    I'm using thymeleaf and the form-action should be defined like this: th:action="@{/test}"
    CH4:D
    @chad_d_stud_twitter
    Question, does the sequence of the ServerHttpSecurity matter?
    I’m trying to convert the following from an existing non-reactive code:
     @Bean
        SecurityWebFilterChain springWebFilterChain(ServerHttpSecurity http) {
            // Spaces show where the old code use to be separated.
            return http
                    .csrf()
                    .disable()
    
                    .addFilterBefore(new AuthenticationWebFilter(), SecurityWebFiltersOrder.HTTP_BASIC)
                    .authorizeExchange()
                    .pathMatchers("/v1/**")
                    .authenticated()
                    .and()
    
                    .exceptionHandling()
                    .authenticationEntryPoint(authenticationExceptionHandler)
                    .accessDeniedHandler(customAccessDeniedHandler)
    
                    // This used to be part of configure() in SecurityConfiguration()
                    .and()
                    .authenticationManager(customAuthenticationProvider)
    
                    .cors()
                    .and()
                    .build();
        }
    James Howe
    @OrangeDog
    Where can I give feedback on this? Raise a github issue?
    https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Features-Matrix
    Andreas Falk
    @andifalk
    @OrangeDog what Feedback do you have here?
    James Howe
    @OrangeDog
    Primarily that it appears to have a narrow definition of "opaque token" as implemented in Spring Security of "arbitrary string that you make a web request to the auth server to get the details of" instead of what Spring Security OAuth has also implemented - "arbitrary string that can be looked up via any method, in particular a JDBC, Redis or in-memory database shared with the auth server"
    James Howe
    @OrangeDog
    More generally, it doesn't capture what SSO allows you to customise and extend at a single point, but which SS perhaps doesn't. Going by what I'm using, that's the aforementioned TokenStore, but also the TokenGranter, RequestFactory, RequestValidator, and ConsumerTokenServices.
    I've got lots of bits put together so I could build a page to view and revoke the access that you've granted.
    James Howe
    @OrangeDog
    Basically, I'm concerned everything I'm using is going to be left out from the "feature parity"
    Andreas Falk
    @andifalk
    @OrangeDog Spring Security 5 implementation is more strict to what the OAuth 2.0 and OpenID Connect specs define. Regarding opaque tokens, the OAuth 2.0 standard only defines an introspection endpoint (https://tools.ietf.org/html/rfc7662) to validate such a token. Additionally, the OpenID Connect specification defines a user info endpoint (https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) to ask for more user details using an access token. All other means like "arbitrary string that can be looked up via any method, in particular, a JDBC, Redis or in-memory database shared with the auth server" are not according to the standard and bear security risks. Especially the database of the auth server should be used exclusively by the auth server and must not be shared with any other party!
    In case you want to persist tokens in your OAuth2/OIDC client then you have to implement the interface "OAuth2AuthorizedClientRepository" yourself to store data it into a database (e.g. Redis). The default implementation just stores the data in the HTTP session.
    James Howe
    @OrangeDog
    As I feared. There are no specific standards for other opaque token implementations, because they don't require different systems to talk to each other, so there's no need to define any public communication protocols. It is very common that the auth server and the resource server are the same party, even implemented in the same process.
    The core OAuth 2.0 spec says you can implement bearer and authorisation tokens however you please.
    I'm not maintaining a client, I'm maintaining a web service that allows other developers to use its api.
    Andreas Falk
    @andifalk
    So what you are implementing is a resource server.
    James Howe
    @OrangeDog
    and an auth server
    Andreas Falk
    @andifalk
    In OAuth2 you have a clear separation of concerns: Auth Server, Client and Resource Server. That is basically the basic idea of OAuth2.
    James Howe
    @OrangeDog
    I know that. And my application as a whole includes both an auth server and a resource server.
    And in a minimal deployment, they're the same process.
    Just like every web service that both has its own accounts and offers api access
    But Spring Security seems to be taking a very narrow view of what OAuth is and completely cutting out this use case, that was amply served by Spring Security OAuth
    Andreas Falk
    @andifalk
    That is what Spring Security OAuth just provided with its "EnableAuthorizationServer"/"EnableResourceServer" annotations. With these, you could implement an AuthServer also providing a user info endpoint (which acted like a resource server). You won't find this with any other OAuth/OIDC provider like Keycloak, Okta etc.
    James Howe
    @OrangeDog
    Obviously not, because those are ID providers. They're not systems like Facebook or Google or Github that have their own accounts and also a developer api.
    OAuth is not just an authentication/ID system.
    Jeff Beck
    @beckje01
    Maybe I missed something (its likely I did) is there a move to deprecate the EnableAuthorizationServer path?
    James Howe
    @OrangeDog
    The entirely of Spring Security OAuth is being deprecated this week
    Jeff Beck
    @beckje01
    OK so yes I'm a bit behind
    James Howe
    @OrangeDog
    but Spring Security does not have feature-parity
    Stephan R
    @mrpubnight_gitlab

    Hoping to get a little help about configuring multiple OAuth2 IDPs in our Spring Boot API Gateway. We are currently using Zuul but are also PoCing Spring Cloud Gateway so either is relevant.

    We'd like to use tenant URLs for our Federated users each using a different IDP for authentication but ultimately have them go through the same gateway. Is there a way to switch OAuth configurations based on the tenant of the URL? A couple considerations; 1) we do not want a login selector screen - we'd like to manage that through different security configurations, 2) the redirect URL should contain the tenanted URL. Is this possible? Easy/Hard?

    James Howe
    @OrangeDog
    and from what Andreas is saying, it sounds like it never will
    Andreas Falk
    @andifalk
    But for Facebook, Google or Github this just the same. They also separate the OAuth2 token retrieval process from using their APIs with such a token.
    Spring Security OAuth has been a bit insecure implementation that is why Spring switched to use Nimbus SDK to do the OAuth2 stuff instead of implementing it themselves.
    @OrangeDog If you are looking for a multi-tenant IDP feature, this has been added in Spring Security 5.2 (https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#oauth2resourceserver-multitenancy).
    James Howe
    @OrangeDog
    I can guarantee to you, they do not solely use RFC 7662.
    I am simply looking for opaque tokens that are not implemented using RFC 7662
    I am not interested in IDP at all - you are exactly proving my point that you have a very narrow view of OAuth. It is not an identity provider protocol!
    It is very frustrating, having been involved in the development of OAuth2.0, to see Spring discarding all the deliberate flexibility in a misguided view that if there's no published RFC then it's not a valid method of implementation.
    Andreas Falk
    @andifalk
    Yes, OAuth 2 is an authorization delegation framework, for authentication you need OIDC. But what you want to achieve is not part of the OAuth 2.0 standard as well. Facebook, Google might just have additional features compared to standard OAuth2.
    James Howe
    @OrangeDog
    The OAuth 2.0 standard is not a description of implementation details.
    Andreas Falk
    @andifalk
    Yes that is why OAuth 2.0 is named a framework. But OAuth 2.0 does NOT define any specific token type.
    James Howe
    @OrangeDog
    Exactly
    So why are you insisting that the only valid implementation of an opaque token is required to use RFC 7662?
    The token may denote an identifier used to retrieve the authorization
    information
    that's all I want
    that's what Spring Security OAuth provides
    in contrast, Spring Security lacks even a basic getTokenDetails(String token) interface
    Andreas Falk
    @andifalk
    Yes, this is correct. You may use opaque tokens in any way you want. But if you want to use opaque tokens together with OAuth 2.0 then RFC 7662 clearly defines how to validate such tokens in this case. Spring Security OAuth neglected these standards
    James Howe
    @OrangeDog
    This specification defines a method
    a method, not "the exclusively valid MUST use method"
    Which should be obvious, because it was written three years after RFC 6749, and five years after RFC 5849
    When I say "opaque token" I mean token as decscribed by RFC 6749
    as opposed to a self-encoding token, of which the only common example is JWT
    Andreas Falk
    @andifalk
    Basically you may do what you want with such opaque tokens. But how do you want to validate these if you do not want to use token introspection? What I mean is that if you do your "own thing" and do not use those standards then you take the risk of being potentially insecure. All these specifications have been written for good reason by some of the best security experts.
    James Howe
    @OrangeDog
    I've already given the obvious examples of what Spring Security OAuth has. You have shared storage that the auth server can write to and the resource server can read from.