oauth2 + spring session + failover

Question

oauth2 + spring session + failover

bilak opened this issue 8 years ago · comments

I'm trying to follow your double example. I'm trying to create sample where I want to have users authenticated/authorized with oauth2 and if possible session persisted in jdbc (to support basic failover in replicated application).
Instead of working with cookie, I'd like to work with http headers only. My current issue is that when I get to gateway at localhost:8080/login, what will forward me to uaa service at localhost:8080/uaa/login will generate another csrf token and after successful login it complains about the token found in header which is basically the token from gateway.

Is it somehow possible to "share" csrf between application contexts? I'm thinking about spring session for this.
Can you please share some solution to have oauth2 + spring session working?

Many thanks

Dave Syer · Answer 1 · Mon May 30 2016 22:45:15 GMT+0800 (China Standard Time)

I don't think there is a JDBC implementation of Spring Session (I might be wrong I guess). If there was it would be pretty routine to install it. Why not get it working with Redis first? All you need to do is declare the dependencies for vanilla use cases.

Lukáš Vasek · Answer 2 · Mon May 30 2016 22:54:20 GMT+0800 (China Standard Time)

There already is EnableJdbcHttpSession and that's not problem to configure. But at first I just want to know if there is some possibility to resolve my csrf issue without disabling csrf.
Thanks

Dave Syer · Answer 3 · Tue May 31 2016 00:21:17 GMT+0800 (China Standard Time)

I don't understand the question then. If you have spring session set up correctly then everything you need is there in the session.

Lukáš Vasek · Answer 4 · Tue May 31 2016 21:42:17 GMT+0800 (China Standard Time)

@dsyer problem is, that if I use the header HeaderHttpSessionStrategy and click on one of those two link which are navigating to /ui or /admin I'm asked for credentials (basic auth), because there is only header information (x-auth-token) and no cookie. So here is the question how to pass headers or if it's even possible while using only header strategy.

Dave Syer · Answer 5 · Tue May 31 2016 23:31:59 GMT+0800 (China Standard Time)

Why do you want to use the header strategy? A UI with a browser client (like an auth server) is better with the default cookie strategy, I would have thought. I feel like maybe I'm missing something.

Lukáš Vasek · Answer 6 · Tue May 31 2016 23:54:02 GMT+0800 (China Standard Time)

I'm thinking about header strategy, because in the future I'd like to have some /api accessible for external services (not implemented by me). So for this I just want to create auth with header strategy. But maybe I'm thinking about it in bad way and it could be achieved simpler. Maybe I can add header in header filter to have both of them (cookie + header).

Lukáš Vasek · Answer 7 · Wed Jun 01 2016 22:21:48 GMT+0800 (China Standard Time)

@dsyer I have now following application. It's based on your double and authorization server from oauth2. Instead of using JWT I've configured auth server to use inmemory store and I'm using redis to store sessions in backend store. Now when I access url localhost:8080 I'm redirected to localhost:9999/uaa/login what is ok. Then I log in, approve the ticket and after that, I'm navigated back to localhost:8080 but instead of index.html I'm getting localhost:8080/login?error=access_denied&error_description=User%20denied%20access&state=lJUt7S. Please can you tell me what am I missing here?
Thank you

Dave Syer · Answer 8 · Wed Jun 01 2016 23:33:30 GMT+0800 (China Standard Time)

From error_description=User denied access I would say that maybe the user denied access in the auth server?

Lukáš Vasek · Answer 9 · Thu Jun 02 2016 00:09:09 GMT+0800 (China Standard Time)

@dsyer thanks...I've added GlobalAuthenticationConfigurerAdapter to have two users. Now after token approval I have following Authentication request failed: org.springframework.security.authentication.BadCredentialsException: Could not obtain access token. Has it something to do with token approval?
Edit:
Just to mention exception is now Possible CSRF detected - state parameter was required but no state could be found. I'm currently using in every application annotation @EnableResourceServer. Do I need it for each application or is it better to use '@EnableOAuth2Client'? I don't follow the differences right now.

Lukáš Vasek · Answer 10 · Tue Jun 07 2016 20:19:42 GMT+0800 (China Standard Time)

@dsyer can you please help me to resolve I hope last issue (application is updated an seams to be working)? Currently when I authenticate on uaa server I'm navigated back to gateway at localhost:8080/login. Problem is that gateway doesn't know about session as can be viewd in 2.nd step in securityfilterchain (SecurityContextPersistenceFilter) .
When I access url localhost:8080 after prvious steps, I'm able to access to UI and work further.
I think I must somehow tell the gateway to use the session which was created during authentication at uaa. But is it right decision or should I do something completely different?

Thanks

o.s.s.web.DefaultRedirectStrategy        : Redirecting to 'http://localhost:9999/uaa/oauth/authorize?client_id=acme&redirect_uri=http://localhost:8080/login&response_type=code&state=x7GTpX'
o.s.s.web.util.matcher.OrRequestMatcher  : Trying to match using Ant [pattern='/css/**']
o.s.s.w.u.matcher.AntPathRequestMatcher  : Checking match of request : '/login'; against '/css/**'
o.s.s.web.util.matcher.OrRequestMatcher  : Trying to match using Ant [pattern='/js/**']
o.s.s.w.u.matcher.AntPathRequestMatcher  : Checking match of request : '/login'; against '/js/**'
o.s.s.web.util.matcher.OrRequestMatcher  : Trying to match using Ant [pattern='/images/**']
o.s.s.w.u.matcher.AntPathRequestMatcher  : Checking match of request : '/login'; against '/images/**'
o.s.s.web.util.matcher.OrRequestMatcher  : Trying to match using Ant [pattern='/**/favicon.ico']
o.s.s.w.u.matcher.AntPathRequestMatcher  : Checking match of request : '/login'; against '/**/favicon.ico'
o.s.s.web.util.matcher.OrRequestMatcher  : Trying to match using Ant [pattern='/error']
o.s.s.w.u.matcher.AntPathRequestMatcher  : Checking match of request : '/login'; against '/error'
o.s.s.web.util.matcher.OrRequestMatcher  : No matches found
o.s.s.w.u.matcher.AntPathRequestMatcher  : Request '/login' matched by universal pattern '/**'
o.s.security.web.FilterChainProxy        : /login?code=nYd9AN&state=x7GTpX at position 1 of 12 in additional filter chain; firing Filter: 'WebAsyncManagerIntegrationFilter'
o.s.security.web.FilterChainProxy        : /login?code=nYd9AN&state=x7GTpX at position 2 of 12 in additional filter chain; firing Filter: 'SecurityContextPersistenceFilter'
w.c.HttpSessionSecurityContextRepository : No HttpSession currently exists
w.c.HttpSessionSecurityContextRepository : No SecurityContext was available from the HttpSession: null. A new one will be created.
o.s.security.web.FilterChainProxy        : /login?code=nYd9AN&state=x7GTpX at position 3 of 12 in additional filter chain; firing Filter: 'HeaderWriterFilter'
o.s.s.w.header.writers.HstsHeaderWriter  : Not injecting HSTS header since it did not match the requestMatcher org.springframework.security.web.header.writers.HstsHeaderWriter$SecureRequestMatcher@23658495
o.s.security.web.FilterChainProxy        : /login?code=nYd9AN&state=x7GTpX at position 4 of 12 in additional filter chain; firing Filter: 'CsrfFilter'
o.s.security.web.FilterChainProxy        : /login?code=nYd9AN&state=x7GTpX at position 5 of 12 in additional filter chain; firing Filter: 'LogoutFilter'
o.s.s.w.u.matcher.AntPathRequestMatcher  : Request 'GET /login' doesn't match 'POST /logout
o.s.security.web.FilterChainProxy        : /login?code=nYd9AN&state=x7GTpX at position 6 of 12 in additional filter chain; firing Filter: 'OAuth2ClientAuthenticationProcessingFilter'
o.s.s.w.u.matcher.AntPathRequestMatcher  : Checking match of request : '/login'; against '/login'
uth2ClientAuthenticationProcessingFilter : Request is to process authentication
uth2ClientAuthenticationProcessingFilter : Authentication request failed: org.springframework.security.authentication.BadCredentialsException: Could not obtain access token
uth2ClientAuthenticationProcessingFilter : Updated SecurityContextHolder to contain null Authentication
uth2ClientAuthenticationProcessingFilter : Delegating to authentication failure handler org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler@2536a681
.a.SimpleUrlAuthenticationFailureHandler : No failure URL set, sending 401 Unauthorized error
w.c.HttpSessionSecurityContextRepository : SecurityContext is empty or contents are anonymous - context will not be stored in HttpSession.
s.s.w.c.SecurityContextPersistenceFilter : SecurityContextHolder now cleared, as request processing completed

Dave Syer · Answer 11 · Tue Jun 07 2016 20:34:14 GMT+0800 (China Standard Time)

I'm not sure I follow that, but it's normal to have 2 sessions (one at the auth server and one at the client app). So I don't think there's an issue with the sessions or cookies. Your logs say "Could not obtain access token". So that would be an issue (probably a config error).

Lukáš Vasek · Answer 12 · Tue Jun 07 2016 21:03:56 GMT+0800 (China Standard Time)

@dsyer it debug it looks like the AccessTokenRequest.preservedState is null hovewer state is provided in requests /login?code=nYd9AN&state=x7GTpX. Am I missing something?

Dave Syer · Answer 13 · Tue Jun 07 2016 21:09:22 GMT+0800 (China Standard Time)

Do you actually have a session on the client app? If not that could be the problem.

Lukáš Vasek · Answer 14 · Tue Jun 07 2016 21:34:34 GMT+0800 (China Standard Time)

@dsyer I'm sharing the session using spring-session (persited in redis) so it should be there. But while I have @EnableOAuth2Sso on gateway I think it won't create the session on the gateway application (in this case the client) - I think I'm navigate dirrectly to uaa. Should the @EnableResourceServer help here or is there any pattern which to follow?

Dave Syer · Answer 15 · Tue Jun 07 2016 21:40:20 GMT+0800 (China Standard Time)

@EnableOAuth2Sso doesn't prevent a session from being created. Look at your requests and responses in the browser and try to see where the cookies get set and unset.

Lukáš Vasek · Answer 16 · Tue Jun 07 2016 22:02:09 GMT+0800 (China Standard Time)

@dsyer you are right, cookies are created. But I don't understand what's going on in that last 3 steps

GET / HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: sk,cs-CZ;q=0.8,cs;q=0.6

HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Set-Cookie: SESSION=7af6f797-19a4-41f5-9d3f-8d0a935f6d9e; Path=/; HttpOnly
Location: http://localhost:8080/login
Content-Length: 0
Date: Tue, 07 Jun 2016 13:56:21 GMT

GET /login HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: sk,cs-CZ;q=0.8,cs;q=0.6
Cookie: SESSION=7af6f797-19a4-41f5-9d3f-8d0a935f6d9e

HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Location: http://localhost:9999/uaa/oauth/authorize?client_id=acme&redirect_uri=http://localhost:8080/login&response_type=code&state=C1ZFiz
Content-Length: 0
Date: Tue, 07 Jun 2016 13:56:21 GMT

GET /uaa/oauth/authorize?client_id=acme&redirect_uri=http://localhost:8080/login&response_type=code&state=C1ZFiz HTTP/1.1
Host: localhost:9999
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: sk,cs-CZ;q=0.8,cs;q=0.6
Cookie: SESSION=7af6f797-19a4-41f5-9d3f-8d0a935f6d9e

HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Location: http://localhost:9999/uaa/login
Content-Length: 0
Date: Tue, 07 Jun 2016 13:56:21 GMT

GET /uaa/login HTTP/1.1
Host: localhost:9999
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: sk,cs-CZ;q=0.8,cs;q=0.6
Cookie: SESSION=7af6f797-19a4-41f5-9d3f-8d0a935f6d9e

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
X-Application-Context: application:9999
Content-Type: text/html;charset=UTF-8
Content-Language: sk
Transfer-Encoding: chunked
Date: Tue, 07 Jun 2016 13:56:21 GMT

POST /uaa/login HTTP/1.1
Host: localhost:9999
Connection: keep-alive
Content-Length: 72
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:9999
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost:9999/uaa/login
Accept-Encoding: gzip, deflate
Accept-Language: sk,cs-CZ;q=0.8,cs;q=0.6
Cookie: SESSION=7af6f797-19a4-41f5-9d3f-8d0a935f6d9e

HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Set-Cookie: SESSION=7712e5ee-583d-4503-a6c4-349ced3d1b79; Path=/uaa/; HttpOnly
Location: http://localhost:9999/uaa/oauth/authorize?client_id=acme&redirect_uri=http://localhost:8080/login&response_type=code&state=C1ZFiz
Content-Length: 0
Date: Tue, 07 Jun 2016 13:56:40 GMT

GET /uaa/oauth/authorize?client_id=acme&redirect_uri=http://localhost:8080/login&response_type=code&state=C1ZFiz HTTP/1.1
Host: localhost:9999
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Referer: http://localhost:9999/uaa/login
Accept-Encoding: gzip, deflate, sdch
Accept-Language: sk,cs-CZ;q=0.8,cs;q=0.6
Cookie: SESSION=7712e5ee-583d-4503-a6c4-349ced3d1b79; SESSION=7af6f797-19a4-41f5-9d3f-8d0a935f6d9e

HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
X-Application-Context: application:9999
Location: http://localhost:8080/login?code=NntBz1&state=C1ZFiz
Content-Language: sk
Content-Length: 0
Date: Tue, 07 Jun 2016 13:56:40 GMT

GET /login?code=NntBz1&state=C1ZFiz HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Referer: http://localhost:9999/uaa/login
Accept-Encoding: gzip, deflate, sdch
Accept-Language: sk,cs-CZ;q=0.8,cs;q=0.6
Cookie: SESSION=7af6f797-19a4-41f5-9d3f-8d0a935f6d9e

HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Set-Cookie: SESSION=ea63d65e-84d2-49b9-9afe-6d13c098a3a9; Path=/; HttpOnly
Content-Type: text/html;charset=UTF-8
Content-Language: sk
Content-Length: 342
Date: Tue, 07 Jun 2016 13:56:40 GMT

Dave Syer · Answer 17 · Tue Jun 07 2016 22:08:19 GMT+0800 (China Standard Time)

That all looks good to me (except the 401 of course). It seems like you have screwed up the client configuration somehow. What makes you think the problem is with the state in the session? Look at DEBUG logs on the auth server to find out why the access token is not granted?

Lukáš Vasek · Answer 18 · Tue Jun 07 2016 22:17:28 GMT+0800 (China Standard Time)

@dsyer I've debuged the code and getting this Possible CSRF detected - state parameter was required but no state could be found and in AuthorizationCodeAccessTokenProvider.getParametersForTokenRequest I can see that request.getPreservedState() is returning the null.

This is my client configuration

security:
  sessions: ALWAYS
  oauth2:
    client:
      accessTokenUri: http://localhost:9999/uaa/oauth/token
      userAuthorizationUri: http://localhost:9999/uaa/oauth/authorize
      clientId: acme
      clientSecret: acmesecret
      #registered-redirect-uri: http://localhost:8080
      #use-current-uri: false
      #pre-established-redirect-uri: http://localhost:8080
    resource:
      userInfoUri: http://localhost:9999/uaa/user
  basic:
    enabled: false

and this is uaa config

@Configuration
    @EnableAuthorizationServer
    protected static class OAuth2AuthorizationConfig extends AuthorizationServerConfigurerAdapter {

        @Autowired
        private AuthenticationManager authenticationManager;

        @Bean
        protected AuthorizationCodeServices authorizationCodeServices() {
            return new InMemoryAuthorizationCodeServices();
        }

        @Bean
        AccessTokenConverter accessTokenConverter() {
            return new DefaultAccessTokenConverter();
        }

        @Bean
        TokenStore tokenStore() {
            return new InMemoryTokenStore();
        }

        @Override
        public void configure(ClientDetailsServiceConfigurer clients) throws Exception {
            clients.inMemory()
                    .withClient("acme")
                    .secret("acmesecret")
                    .authorizedGrantTypes("authorization_code", "refresh_token", "password")
                    .autoApprove(".*") // uncomment this to disable approval page
                    .scopes("openid");
                    //.redirectUris("http://localhost:8080");
        }

        @Override
        public void configure(AuthorizationServerEndpointsConfigurer endpoints)
                throws Exception {
            endpoints
                    .authorizationCodeServices(authorizationCodeServices())
                    .accessTokenConverter(accessTokenConverter())
                    .authenticationManager(authenticationManager)
                    .tokenStore(tokenStore())
                    .approvalStoreDisabled();
        }

        @Override
        public void configure(AuthorizationServerSecurityConfigurer oauthServer) throws Exception {
            oauthServer
                    .tokenKeyAccess("permitAll()")
                    .checkTokenAccess("isAuthenticated()");
        }

    }

Dave Syer · Answer 19 · Tue Jun 07 2016 22:43:08 GMT+0800 (China Standard Time)

Does it work without Spring Session?

Lukáš Vasek · Answer 20 · Tue Jun 07 2016 22:47:06 GMT+0800 (China Standard Time)

@dsyer yes it works without Spring Session. Do you have some hint what could be wrong here?

Dave Syer · Answer 21 · Tue Jun 07 2016 22:50:03 GMT+0800 (China Standard Time)

I think the sessions might be colliding in Redis. Your browser is sending 2 cookies to the auth server, and I would only expect one, for instance. How about if you configure the auth server to store sessions in a different database or something?

Lukáš Vasek · Answer 22 · Tue Jun 07 2016 23:12:49 GMT+0800 (China Standard Time)

@dsyer I've disabled the spring-session on uaa and it's working. I'm wondering if the session could be shared from within uaa. I don't understand how those sessions are now working. Please correct me in following steps:

I'm accessing gateway at localhost:8080 where the session=1 is created
I'm navigated by security to localhost:8080/login session=1
While EnableOauthSso is enabled I'm redirected to uaa at localhost:9999/uaa/login where session=1 and new jsessionid=2 is created
When correct credentials are added and clicked on login I'm redirected back to localhost:8080/login with session=1
While session=1 is not authenticated new session=3 is created and this is the session which I should use when I want to have HA

Is it ok from security perspective to have uaa with it's own session?

Many thanks

Dave Syer · Answer 23 · Wed Jun 08 2016 00:02:31 GMT+0800 (China Standard Time)

Is it ok from security perspective to have uaa with it's own session?

That's normal. I don't know why you would have any concerns about that.

I think this is probably a bug in Spring Session (2 cookies with different paths shouldn't collide like that). Maybe you could create a new ticket there?

Lukáš Vasek · Answer 24 · Wed Jun 08 2016 00:17:34 GMT+0800 (China Standard Time)

@dsyer I've created spring-projects/spring-session#543.
Now when I look into redis everytime when I access the context /admin or /ui new sessions are created. Is it possible to don't create new sessions and somehow reuse those existing? I've already configured spring.sessions=never to test this behaviour in admin and ui applications, but sessions are still created.

Dave Syer · Answer 25 · Wed Jun 08 2016 00:19:59 GMT+0800 (China Standard Time)

I don't think you should be sharing sessions between the app and the auth server. That's what is causing all the problems.

N.B. spring.sessions=never is not a valid config setting from Spring Boot AFAIK, so I wouldn't expect it to do anything. But security.sessions=never would be a bad idea - you need sessions in both places.

Lukáš Vasek · Answer 26 · Wed Jun 08 2016 00:30:35 GMT+0800 (China Standard Time)

@dsyer sorry that was my typo I used security.sessions=never.
About that sharing - I mean share sessions between the UI applications. Not auth server.
And more specificially...
If I create session for admin application and then navigate to ui application and there will be created new session that doesn't matter = that's one session per application for user (if sessioin could be shared between these two apps that's great).
But if I navigate to admin with new session then to ui with new session and then back to the admin with new session there will be a lot of session in sessionstore. So I just want to avoid this "unnecessary" session creation while navigating between applications.
I don't know if you get what I mean, if not I will explain in more detail.

Dave Syer · Answer 27 · Wed Jun 08 2016 00:48:00 GMT+0800 (China Standard Time)

I don't get it. All those sessions are necessary. You just have to avoid them sharing storage (I think that's the bug).

Lukáš Vasek · Answer 28 · Wed Jun 08 2016 14:33:56 GMT+0800 (China Standard Time)

@dsyer when I'm navigating between apps:

on gateway new session g1 is created
navigating to ui new u1 session is created
navigating to adminapp new a1 session is created
navigating to ui new u2 session is created
navigating to adminapp new a2 session is created

so I was thinking about steps 4 and 5 when I want to reuse sessions created in earlier steps instead of creating new one. So in step 4 use u1 and in step 5 use a1. Is this somehow possible or I'm thinking wrong about it?

All those sessions are necessary. You just have to avoid them sharing storage (I think that's the bug).

Why avoid sharing storage? As I read that could be potential security issue. I'm still thinking about high availability and failover in case something goes wrong. Would it be ok if I store sessions to separate spaces in redis per application?

Dave Syer · Answer 29 · Wed Jun 08 2016 14:46:55 GMT+0800 (China Standard Time)

I believe there is a bug which mixes up the storage between your gateway and your auth server in redis (since the two systems work fine if only one of them has a redis session). That's not (just) a security issue, it's a bug that prevents you from authenticating in your gateway. Properly sharing sessions between the auth server and the gateway might fix that, but it might even be better if they are separate anyway (which we know works fine).

There is always a security risk with sharing session data, but you can make rational decisions about that. If two processes are part of the same app logically and you control them both, then it's not completely crazy to share a session between them. But on the other hand, since the only thing I would store in the session is security data (like an access token for instance), there isn't necessarily a huge benefit in doing so. Shared session data is better as a means of scaling up a single process to many of the same type IMO, not so much for creating large distributed apps.

Pascal Lalonde · Answer 30 · Sun Feb 18 2018 03:32:22 GMT+0800 (China Standard Time)

May I ask about the actual fix here? I am having the same exact behavior, but the oauth server does not share any session with client application.
But, client application is using redis as session store.

It seems that the OAuth2ClientContext preserved state is always empty when the user is redirected from the login screen. Because of that, I am getting a 401, because the request as a state, but not the context?

I took a look at what is stored in redis, but the keys only shows the SPRING_SECUIRTY_SAVED_REQUEST without anything related to the state?

Dave Syer · Answer 31 · Sun Feb 18 2018 06:57:30 GMT+0800 (China Standard Time)

I don’t think that’s the same problem then is it? Does the code from the “complete” sample work for you? If it does then there isn’t really an issue with the guide, I guess.

Pascal Lalonde · Answer 32 · Sun Feb 18 2018 08:11:57 GMT+0800 (China Standard Time)

Yes indeed, I just realized that when redis is configured to persist as json, it will miss some of the objects to be serialized, compared to the default jdk serialization strategy. The context being one of them.