Revoke access token

ubuntudroid · July 13, 2020, 6:13pm

As far as I understand squidex uses identity-server to manage authentication. From identity-server’s documentation I see, that it supports token revocation.

However the endpoint doesn’t seem to exist for squidex (at least not in the cloud version). Is it a different endpoint or is this feature not supported at all? I want to test re-authentication before shipping my app.

Sebastian · July 13, 2020, 6:16pm

I have never tested it before, but the identity server endpoints are under /identity-server/ prefix, so it should be /identity-server/connect/revocation.

BUT we do not use reference tokens, it is a JWT token https://identityserver4.readthedocs.io/en/stable/topics/reference_tokens.html

ubuntudroid · July 13, 2020, 6:21pm

Hm, I’m getting a 404 when trying to access https://cloud.squidex.io/identity-server/connect/revocation. But you are right, I missed the fact, that squidex is using JWT tokens and not reference tokens and only the latter seems to be supported by the endpoint anyway.

Is there another way to test token revocation without deleting the whole client in squidex?

Sebastian · July 13, 2020, 6:22pm

No, not at the moment. I would just handle 401s in general.

This is how I handled it in c# client library:

github.com

Squidex/squidex-samples/blob/master/csharp/Squidex.ClientLibrary/Squidex.ClientLibrary/Utils/AuthenticatingHttpClientHandler.cs

// ==========================================================================
//  Squidex Headless CMS
// ==========================================================================
//  Copyright (c) Squidex UG (haftungsbeschraenkt)
//  All rights reserved. Licensed under the MIT license.
// ==========================================================================

using System.Net;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Threading;
using System.Threading.Tasks;

namespace Squidex.ClientLibrary.Utils
{
    public sealed class AuthenticatingHttpClientHandler : HttpClientHandler
    {
        private readonly IAuthenticator authenticator;

        public AuthenticatingHttpClientHandler(IAuthenticator authenticator)

This file has been truncated. show original

I have basically an in-memory-cache with a 30 days expiration and when I get a 401, I remove the token from the cache and then the next call will work.

ubuntudroid · July 13, 2020, 6:29pm

Right, that’s what I’m doing as well - but you know how it goes. You think it should work fine, but with several thousands of users on hundreds of different devices and networks out there things go wrong all the time. Therefore I was hoping to be able to test before rolling out.

Would there be any possibility to maybe allow setting a shorter lifetime for access tokens of certain clients? That might already do the trick.

Sebastian · July 13, 2020, 6:31pm

I think this would be complicate things more. I could add query strings or so to the API to simulate errors?

e.g. /endpoint?error=500 throws a 500, so you can simulate it.

ubuntudroid · July 13, 2020, 6:35pm

Now that would be sweeeeeet!

If you find the time I’d much appreciate it! For now I’ll just change the locally stored token to an invalid one after a few calls and thus force a 401 from the server.

Sebastian · July 13, 2020, 8:10pm

I have a PR, but it is not deployed yet.