OIDC + Authentik: Which token to give to user for authentication?

Question

I am implementing a web service with a front end and back end. Everything but the login endpoint requires authentication. For authentication I use Authentik. However, I have trouble wrapping my head around which tokens to give to the user, given Authentik's configuration options.

Currently, my authentication process works as follows:

1. On login, the user is sent to the OIDC provider's authorization endpoint and comes back with an access_code.
2. Back end sends the access_code to the token endpoint to retrieve the id_token, access_token and refresh_token.
3. Back end sends the id_token and refresh_token to the user and discards the access_token (I only need to know if the email address is a company email, which is already included in the id_token). The id_token and refresh_token are stored as cookies (Secure, HttpOnly, SameSite=strict).
4. Whenever the user makes a request to an endpoint requiring authentication, I check the signature on the id_token, the intended audience (aud) and the expiration time (exp). If those checks pass, I trust the email address in the user-supplied id_token.
5. If the ID token is expired, I use the refresh_token with the token endpoint to get a new id_token and refresh_token.
6. If the user logs out by themselves, I use the revocation endpoint to revoke both the refresh_token and the id_token. Afterwards, the cookies are deleted.
7. If the user needs to be logged out by me (left the company), I remove the user's ability to use their company email with Authentik. Then, the next time the id_token expires, the refresh will fail and the user will not get a new id_token. This means that after one expiration period, the user will be logged out automatically.

I have implemented these steps and the process works quite nicely. I currently do not need to create my own session cookies or sign my own JWTs with a persistent secret, which I would like to keep.

However: Authentik does not provide a way to configure the id_token expiration period. I can only configure that for the access_code, access_token and refresh_token. The lack of documentation on that leads me to believe that I might have misunderstood OIDC.

Could someone enlighten me on this?

EDIT: As a hacky workaround, I've made my backend reject ID tokens that are older than 5 minutes. This is implemented by checking the iat ("issued at") claim. Effectively, my backend now treats ID tokens as having an expiry time of 5 minutes. This perfectly suits my use case. However, I find it confusing that I wasn't able to find a more "proper" solution in OIDC and that I haven't found any guides that highlight this exact problem.

Answer 1

You need access token to limit authorization and roles of the caller and to identify the caller, you need an ID token. Together they build authorization and authentication. If your web service has administration and/or premium APIs to which only certain users get access, you have to give access token to the user so that your APIs can individually validate roles and permissions at the time of being called by the user. As you are discarding access token, I'm assuming your users have equal authorization to access resources of your web service.

You can still improve your session management by not going off-spec from OIDC and for that you do need access token for the following:

If the ID token is expired, I use the refresh_token with the token endpoint to get a new id_token and refresh_token.

1. You don't have to refresh the access token just to get a fresh ID token. Instead, use access token and call /userinfo endpoint to get the fresh ID token. If the user has been removed from the organization, you won't be able to use that access token to retrieve a new ID token so your web service can immediately clears the session of the user.

2. Access token can be re-verified live by the identity provider (IdP) by using Token Introspection. So, if the user has been removed from the organization, instead of waiting for the token to get expired, your APIs can use token introspection to know that the access token has been revoked before giving access. This will also prevent a small window of attack in which the user has been removed from the org but its cookies still has unexpired access token which can be used to continue using your service.

3. Unlike access token, ID token can neither be introspected nor be forcefully revoked.

Note: As token introspection request makes I/O with the IdP, it should be periodically used in cases like if the user was inactive for a while or if the cache of token introspection response has expired. If the access token has already expired, there is no need to make token introspection request for that token.

---

If the user logs out by themselves, I use the revocation endpoint to revoke both the refresh_token and the id_token. Afterwards, the cookies are deleted.

OIDC has RP-Initiated Logout for this in which when the user initiates logs out, access and refresh token are revoked at the IdP's end, the web service clears cookies of the user and logs out the user on the web app.

If the user needs to be logged out by me (left the company), I remove the user's ability to use their company email

OIDC has Back-Channel Logout for this in which the IdP revokes tokens and issues the logout request to your web service and your web service logs out the user.

Authentik does not provide a way to configure the id_token expiration period. I can only configure that for the access_code, access_token and refresh_token.

Then you should use a short-lived access token and give it to the user.