Dealing with expirations and revocations

[spietras]

Hi. I wanted to ask about some details of how it works before deciding whether to go with this way of authentication.

Let's take a simple scenario as an example. I have a Next.js app that sits behind Traefik with this middleware. The app has a single page containing a single button that performs a server action when clicked. So there are two requests involved:

• GET request on first load or any full page refresh to get the page content that the browser will display
• POST request that the browser will send to the server after clicking a button

I get how this middleware works at first when everything is fresh and new, but I'm interested in what happens when things start to expire or get revoked. I would like to prevent surprises for users like sudden redirects in the middle of doing something.

The questions I have in my mind at the moment:

1. If I understand correctly, this middleware will create a cookie after successful validation of the response from the IdP. This cookie will expire at some point. How likely is that? Is the cookie set only once per login after returning from the IdP? Or is it refreshed on every request going through the middleware, which would mean it doesn't expire if the user is actively making requests?
2. Are refresh tokens used to transparently get a new set of tokens from the IdP? If so, when is that happening? Asynchronously in the background? Synchronously on every or some requests? What happens when the refresh token itself expires? What happens when the refresh token gets revoked and the IdP rejects it?
3. This might be a bit too specific, but maybe you know the answer. If the middleware decides that the user should log in, then it redirects the request to the IdP. If that happens when the user loads the page initially or does a full page reload, then it's quite clear what happens: the browser will redirect the user. But do you know what happens when the browser is making a request to the server, like in the server action case? Will the browser redirect the user, or does there need to be some client-side handling of the response?

[sevensolutions]

Hi @spietras,
all excellent questions 👍

The basic login flow is documented here:
https://traefik-oidc-auth.sevensolutions.cc/docs/getting-started/how-it-works

So in your scenario the following will happen:

• The initial page load request will stop at the middleware because it doesn't contain the middleware's session cookie.
  So it redirects you to the IDP and once you're logged in, it forwards the request upstream.
• Every subsequent request will also include this session cookie, no matter if it's an HTML request or XHR.
• The middleware then validates the cookie and if it's valid, forwards the request

So let me answer your questions one by one:

1. Yes exactly. The cookie is created when your browser navigates to the middleware's callback (/oidc/callback by default). This request finishes the OAuth-auth-code-flow and then creates the cookie which is returned together with the final redirect to your application (back where the user started).
   By default, the session cookie is, well, a session cookie :D This means it will expire when the browser is closed but you can configure a different expiration time by setting SessionCookie.MaxAge. But i have to say i didn't test this case quite well yet.
   What should happen in theory is, that, as long as the IDP has active SSO session, your browser will go through the whole OAuth flow again and then give you a new session cookie, but because the SSO session on the IDP is still active, the user shouldn't need to login again.
   This session cookie is not refreshed on every single request.

2. Yes RefreshTokens are being used and handled transparently. The session cookie contains the whole state (access-, id- and refresh tokens), encrypted using the provided Secret. So as long as the cookie is still valid, the refresh token will be used to renew tokens in case the id-token or access-token (whatever you've configured in Provider.TokenValidation is expired. When this happens a new session cookie is also being created and sent in the client-response.
   When the refresh token itself is expired, the user will get redirected to the IDP login page again and needs to re-login. Again, as in question 1, if an SSO session is still active on your IDP, it should immeditately redirect you back without a login prompt but this highly depends on your IDP.

3. If a request is unauthenticated, the behavior currently depends on the UnauthorizedBehavior configuration which defaults to Challenge. This means the user will get a redirect to the IDP. You can set this to Unauthorized to get a 401 status code instead, but this also affects the initial page load.
   While writing this answer i see that there is room for improvement. The plugin should automatically detect XHR requests and always return a direct 401 status code instead of a redirect so that clients can handle that case.
   Something similar is already implemented when the user is authenticated, but unauthorized (when using Authorization rules).

As a workaround for 3. it may be possible to use two separate middlewares with different UnauthorizedBehavior configs. One for the frontend routes (set to Challenge) and one for the API-routes (set to Unauthorized). But I will create an issue for this to improve it.

[spietras]

Thanks for a quick answer.

Here are some facts that I'm getting from what you are saying:

1. By default, session cookies are used, which last until you close the browser, but you can configure the age to make the cookie persistent (and this is what I would need).
2. The cookie is not refreshed (by refreshing I mean Set-Cookie being there in some response) on every request, but only when either another user-facing authorisation code flow happens or a refresh token is used to obtain new tokens server-side.
3. Refreshing the tokens is done synchronously, when the middleware is executing after a request comes through. Then it checks whether the chosen token is still valid. If not, then the refresh token is used to obtain new tokens.
4. User-facing authorisation code flow might be quick and transparent to the user if the IdP still holds a session for them. Still, a redirect has to happen.
5. The user has to go through the user-facing authorisation code flow again in case the cookie expires, the refresh token expires, or the refresh token gets revoked.
6. If the token of your choice has a short lifespan and the cookie has a long lifespan, and the user is frequently making requests, then the cookie never expires by itself as it will always get refreshed before it expires.
7. The browser does not redirect the user if the response from an AJAX request is a redirect. You need to handle that client-side (I wonder what Next.js specifically does when you have some unexpected response from a server action call, but that's another story...).

And a couple of follow-up questions:

1. Returning different responses based on the type of request sounds like a nice improvement. However, is it even possible to differentiate between these two types reliably? I guess you can check the Accept header for text/html, which should be good enough for usual usage (if we just don't care about AJAX requests with text/html).
2. When using the refresh token to obtain new tokens, the IdP must respond with a new access token, but it may also return a new refresh token (which may or may not have the initial expiry time extended) and a new ID token. Is this middleware prepared to handle all these cases? Are the refresh token and ID token updated if they are present in the response?
3. The IdP might respond with an error when refreshing the tokens with an invalid refresh token. This can happen either by the token being revoked or sending an expired token (probably the middleware doesn't even reach this call if the refresh token is expired, but potentially still can happen due to a time difference between checking the expiry here and when the request reaches the IdP). So just to be sure: are such errors handled appropriately at the moment?
4. There are two cases when you inevitably have to log in (meaning at least be redirected to the IdP) again: the refresh token is revoked, or it expires. Revocation is quite clear, and it should be a sudden thing to the user. But expiry can be expected, assuming you don't have a new refresh token with extended expiry. Would it be possible to send the expiry time to the app so that it can, for example, notify users about an incoming relogin needed?
5. Cookie expiry also requires logging in again, but it's not necessarily inevitable. Inactive users can just perform some action, or a periodic no-op heartbeat request can happen in the background. If any request is made and the chosen token has expired already, then new tokens will be obtained and the cookie will be refreshed. But that relies on careful coordination of lifespans. Would it be possible to simply have the option to extend the cookie on demand with some request? Or maybe even have the option to refresh the cookie on every request?

[sevensolutions]

@ Facts:

1. yes
2. yes
3. yes
4. yes
5. yes
6. Yes, making the cookie having a longer lifetime than the token is required, because the refresh token is also included within the session cookie. So if the session cookie expires before the refresh token, refresh will never work.
7. Yes thats a problem at the moment, I will try to improve that in 🚀 FR: Improve UnauthorizedBehavior do be dynamic based on request #190

@ Questions:

1. Yes I think thats what i'am planning to do. Requests can have multiple Accept headers but if any one says text/html, i will return a direct and a 401 otherwise. I will work on 🚀 FR: Improve UnauthorizedBehavior do be dynamic based on request #190 as soon as i have time and you're welcome to test this.
2. From my understanding of OIDC, a token refresh is always returning a new refresh token. The only edge case i know is that some providers dont return an ID token in a refresh-request. We definetely need to test these cases.
3. In case the refresh token is not valid anymore or some other error occurs while refreshing, the user should be redirect to a normal user-facing login.
4. I'am not sure if I understand that correctly. You mean sending the expiry time to the app on every request?
   The middleware has the concept of custom request headers but the token expiration date is not available right now. But could be added if this would help.
5. Hmm I think both options make sense.

But what i don't really understand right now is: What is your overall use-case or goal?
You want the cookie to have an expiration date but you also want to constantly refresh it so that it never expires? So in other words you want to have a sliding expiration?

[spietras]

From my understanding of OIDC, a token refresh is always returning a new refresh token.

That's not quite true. From OAuth spec:

The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token.

And OIDC spec doesn't change this behaviour, only extends it to possibly include ID tokens:

Upon successful validation of the Refresh Token, the response body is the Token Response of Section 3.1.3.3 except that it might not contain an id_token.

Although in practice, probably most IdPs always issue new refresh tokens.

---

I'am not sure if I understand that correctly. You mean sending the expiry time to the app on every request?

Yes, I mean sending the expiration date of the refresh token to the app using headers. It can be inferred if either the refresh token is a JWT and has an exp claim or the IdP supports introspection for refresh tokens and includes exp field in the response. In most cases, at least one of these is possible.

And yes, custom headers are the perfect place for that. But at the moment, this information is not available to put there. The raw refresh token is not even available.

However, this is only important if the IdP doesn't issue new refresh tokens, doesn't extend the expiry date of new refresh tokens, or if there is a maximum lifetime for a chain of refresh tokens (for example, Auth0 can do this).

But I discovered that my IdP always issues new refresh tokens with an extended expiry date and no maximum lifetime of a chain of tokens. So after all, I don't need this, but someone else might.

---

You want the cookie to have an expiration date but you also want to constantly refresh it so that it never expires? So in other words you want to have a sliding expiration?

Pretty much. Cookies are either non-persistent and expire after closing the browser or persistent and need to have an expiry date.

I want to have persistent cookies, so you don't need to repeat the auth code flow every time you close the browser (although it would be quite transparent to the user if the IdP still holds a session, but it's a better experience without redirects anyway). And I also want to prevent unexpected relogins if the user is active. The only valid case of sudden relogin is when a refresh token gets revoked. If I have persistent cookies, then I need to keep extending their lifespan.

And I think given that

1. My IdP issues refresh tokens with a longer lifetime than the token configured for validation
2. My IdP always issues the token configured for validation with an extended expiry date when refreshing
3. My IdP always issues refresh tokens with an extended expiry date when refreshing
4. The middleware checks on every request if the configured token is still valid
5. The middleware refreshes the tokens when the configured token is no longer valid
6. The middleware updates the cookie with a new set of tokens (including the new refresh token) after refreshing the tokens
7. Updating the cookie extends its lifespan
8. I can configure the cookie age to be longer than the age of the token configured for validation
9. My app does either regular heartbeat requests or prompts the user to perform some action (and then makes a request) if they are inactive

then I think everything works just fine.

The only thing I need is indeed the ability to detect failures in AJAX requests.

---

Sorry for spending so much time on this, but two more questions came to my mind in the meantime:

1. ID tokens are always JWTs, but access tokens and refresh tokens can be either JWTs or opaque. At the moment, the only information needed from these tokens is whether the access token is still valid if it is configured as the token for validation. In case of an opaque access token, the only way to obtain that is either from the token endpoint response directly (expires_in field, which is recommended, but not required) or via an introspection endpoint of the IdP if the IdP supports that (required active field in the response and also optional exp field). Is that supported in the middleware? In other words, does it work with opaque access tokens?
2. Are tokens refreshed only after the configured token stops being valid, or is there some grace period if you know its expiry date? This doesn't matter that much in my case, but there is some time difference between checking the token in the middleware and the app receiving it if you choose to send it. With no grace period, there is an edge case where you check the validity just before it expires, and then after some short time, the app receives an expired token. Having a configurable grace period to refresh the tokens a little bit earlier than their expiry date (assuming you know the date) can prevent such cases from happening in practice.

[sevensolutions]

That's not quite true. From OAuth spec:

Oh yes, you're right. Thx for pointing that out. So in case the IDP does not return a new refresh token, i need to keep the old one.

1. You can set the TokenValidation parameter to Introspection in which case the middleware will call the IDPs introspection endpoint but keep in mind that this is done for every single request. Also this is not very well tested, at least from my side.

2. Yes, currently there is no such grace period.

May I ask you which exact IDP you're using or planning to use?

Also, if you’re planning to use this middleware in production or within a large enterprise, and you need full compatibility with the OIDC standard, you may want to consider using the official enterprise OIDC middleware.

That said, my goal is to continue improving this middleware and make it a solid open-source alternative, but it’s not quite there yet.

[spietras]

Thanks for following up.

You can set the TokenValidation parameter to Introspection in which case the middleware will call the IDPs introspection endpoint but keep in mind that this is done for every single request. Also this is not very well tested, at least from my side.

Ok. Good that this is possible. But I also understand the performance impact. The possibility of using expires_in from the token endpoint response, if available, would be a good addition for someone with opaque access tokens that are used for validation.

Although I'm still undecided on which token to use for validation, by the way. My internal APIs are not protected. They are all in an internal trusted network, so I don't need to forward the access token to them. Only AJAX requests from the browser to the server side of the app (I have Next.js apps, and you can look at it as a BFF pattern) need to be protected, but this would happen by the middleware checking the session cookie. In theory, I could only care about the ID token to know some information about the user, but as an admin, I would also like to be able to forcefully log someone out. And one way to do that is by having short-lived tokens that are used for validation here and refresh tokens that can be revoked. Maybe I will just use short-lived ID tokens and use them for validation here and then the expiry can just be taken from claims... Although not sure if that's how it's meant to be used... Anyway, I'm oversharing 😛

May I ask you which exact IDP you're using or planning to use?

I am using Ory Hydra together with Ory Kratos. All self-hosted, and I have a lot of control over it.

Also, if you’re planning to use this middleware in production or within a large enterprise, and you need full compatibility with the OIDC standard, you may want to consider using the official enterprise OIDC middleware.

That said, my goal is to continue improving this middleware and make it a solid open-source alternative, but it’s not quite there yet.

Yep, I know about enterprise Traefik. But I am only looking for something for my own simple (though properly designed) self-hosting usage and want to stick to free and open source software.

And I found three potential solutions:

1. oauth2-proxy
2. traefikoidc middleware
3. and obviously this traefik-oidc-auth middleware

And I'm just feeling the best vibe with this one. It seems to be nicely designed, apart from some edge cases. You seem to be active and involved in all the issues, pull requests and discussions. So keep up the good work 😉

So at the moment I think I know enough about expirations and revocations. I don't have the whole picture of everything else yet, particularly about logouts, but I will open another discussion if I can't find the answer myself.

Thanks.

Bonus for anyone reading this that also uses Next.js: server actions don't let you see the underlying status code of the response. So I am simply switching to using the classic API routes instead of server actions. And there are tools to make it easier, like tRPC or oRPC.