Session expiry as header

[travisghansen]

Session expiry as header

[travisghansen]

The eas session (cookie) or the jwt expiration?

[kettenbach-it]

I meant the eas session (=cookie) expiration.
The jwt expiration is already in the X-Id-Token-Header.

But let me ask a general question (I'm still struggling to understand oidc):
I'm authenticating an application via traefik + eas to Google OIDC.
On successful authentication, Google sends a token that is valid for 60 minutes. Later it's found in the X-Id-Token-Header.
EAS is configured to set a cookie with expiration in 12 hours, which it does.
The config_token is like this:

features: { cookie_expiry: 43200, userinfo_expiry: true, session_expiry: 43200, session_expiry_refresh_window: 43000, session_retain_id: true, refresh_access_token: true, fetch_userinfo: true, introspect_access_token: false, authorization_token: "access_token" }

As I see right now, the user needs to relogin after 1 hour. Which is too short. It should be 12 hours. How can that be achieved?

BTW: nice software! I used https://github.com/thomseddon/traefik-forward-auth before, but eas has great features!

[travisghansen]

Yeah thanks for the feedback! I got frustrated with many of the solutions out there so built eas overcome those restrictions.

The combination of cookie settings in conjunction with oidc can be quite confusing. Presuming you're validating the expiry on the jwt you'll first need to make sure you're getting a refresh_token from your provider. Usually I see this as an added scope but in the case of Google you need to add a special param to the authentication request. The feature to support this was recently added so it's currently only in the next branch/image. See #51 for more details. Once you have a refresh_token eas can actually attempt to refresh the token behind the scenes (assuming you still have a session..which is where the cookie comes into play).

The server-side sessions used in conjunction with the cookies, store the token(s) in redis (presuming you've activated redis...otherwise in memory). If the cookie expires the browser won't send the session id so even if the server still has the session stored it's effectively dead to the end-user. If the user sends a cookie but the server has expired the session then the data is no longer available to the server and so a new session will need to be started. If both are still valid but the refresh_token is no longer valid you'll need to re-authenticate as well. Also note, sessions will not be refreshed in the absence of user activity...meaning, the server doesn't pro-actively scan sessions and refresh them, the refresh is triggered by the user doing activity during a refresh window.

As you can see, it is an intricate intersection of settings for sure! If you're feeling a little bit confused that's ok...it's confusing! In any case, I can share my settings with you if you'd like. I basically push the cookie and session windows out as far as possible while still letting them actually expire (just for general garbage collection). Then I generally operate in a 'sliding window' sort of scenario based on user activity. If you'd prefer that to the 12 hour setup let me know. If you really want to force 12 hour sessions that's fine, but I'm guessing it's not what you really want here. Keep in mind, if the user is de-activated or whatever the refresh_token will fail to succeed and the session will stop working after the 60-minute window.

Regarding setting the cookie data as a header I think it should be possible, but I'll need to check a couple things to be sure as it may require a little bit of coding. It's actually an area that as I head into a '1.0' release will have breaking changes as I'm going to make the settings for header injection and assertions much more generic. It should be a relatively simple upgrade path, but an upgrade path nonetheless :(

[kettenbach-it]

Thank you very much for your explanation!
And yes: I am interested in your settings and would be pleased, if you shared them. A sliding window is good for me!

After your explanation, the extraction of the expiry date seems to me to be no longer useful or necessary.
The reason for this is that the application I am working on is an Angular Single Page Application in the frontend and a REST-API in the backend.
Since I have delegated the whole topic authentication to the services Traefik, eas and Google, Angular itself has no idea about cookies, tokens, expirydates etc. All these things happen "behind the scenes". The browser simply passes the cookie to the REST-API when the Angular application is called and this way Angular gets access to the API. The API passed things like the userinfo back to the Angular SPA.
However, if the auth_token expires (and there is no refresh_token as in my case), Angular will no longer have access to the API. The only thing the user will notice is that no more data is coming in. Therefore I wanted to have a way to determine the time of the end of authentication, pass this information back to Angular (together with userinfo etc.) and then notify the user and/or reload the SPA. But since this would happen hourly - because, if I understood you correctly, the refresh does not work for me at the moment, - the whole thing is not an option (because too uncomfortable). Further, it would not depend on the session in the cookie but the expiry of the auth-token, which I could get from the X-Id-Token anyway.

Therefore I will now check out the next branch and use the RefreshToken.

[kettenbach-it]

I think this issue can be closed and we'll go ahead in #51

[travisghansen]

@kettenbach-it ok, SPA in this setup can be tricky. I do use it (for example with grafana) but there are ramifications/limitations. Generally they have nothing to do with eas per-se, just the whole idea of 'forward-auth' with SPA can be tricky.

The biggest issue is if an ajax request is triggered and you are no longer authenticated it's not handled cleanly...meaning the browser won't redirect to a login screen etc. In practice, all this can be highly mitigated by have proper refresh setting and big enough windows for your usage pattern that let things stay in order long enough for a 'real'/initial page load to happen.

[travisghansen]

@kettenbach-it here are my settings for the applicable items:

        features: {
          /**
           * if false cookies will be 'session' cookies
           * if true and cookies expire will expire with tokens
           */
          cookie_expiry: false,

          userinfo_expiry: 604800, // 7 days

          session_expiry: 1209600, // 14 days

          session_expiry_refresh_window: 86400,

          session_retain_id: true,

          /**
           * if the access token is expired and a refresh token is available, refresh
           */
          refresh_access_token: true,

          /**
           * fetch userinfo and include as X-Userinfo header to backing service
           */
          fetch_userinfo: true,

          /**
           * check token validity with provider during assertion process
           */
          introspect_access_token: false

          /**
           * which token (if any) to send back to the proxy as the Authorization Bearer value
           * note the proxy must allow the token to be passed to the backend if desired
           *
           * possible values are id_token, access_token, or refresh_token
           */
          //authorization_token: "access_token"
        },
        assertions: {
          /**
           * assert the token(s) has not expired
           */
          exp: true,

          /**
           * assert the 'not before' attribute of the token(s)
           */
          nbf: true,

          /**
           * assert the correct issuer of the token(s)
           */
          iss: true
        },

You may want to adjust the values to something that makes more sense for you. For example, my refresh window is 24 hours. If the session happens to expire over a weekend and your users wouldn't be using the service daily then there's a chance the session would expire and go away. In that case you'd make the window an acceptable value for your team and just run with it.

[travisghansen]

@kettenbach-it I highly recommend reading this as well as you begin using eas with oidc: https://github.com/travisghansen/external-auth-server/blob/master/OAUTH_PLUGINS.md

[kettenbach-it]

I did! I works now.

[travisghansen]

OK, great. Sounds like you're on your way then! Enjoy!