regarding this question How to deal with expiring tokens
I have a similar issue:
I’d like squidex to serve data for my client-side JS. Since I can’t let secrets inside the JS client, I would require to have another server to oauth for my client…
So my question is: is it possible to have an unlimited token for readonly or an option to GET data without any token at all?
Thx
Hi @goldo,
writing a proxy sounds like a good idea for me. So far there is no token that is valid forever but you can request the token as often as you want.
The .NET client library has a custom http client handler that removes the token on 401:
Thanks for your answer, but this seems a bit too much for simple, small apps, blogs or static websites
I am still not sure myself about this point. Permanent api keys have been requested several times. Squidex uses openid connect for authentication, which is a proven a secure model and I wanted to avoid it to create a second authentication flow. I don’t know which backend technology you use but if you just cache the token in memory and delete in on a 401 you can create a helper function with a few lines of code. I give you a professional plan for free for a month if it is more than 20 lines of code 
Unfortunately there is also no simple solution for the javascript problem. As an alternative you can create a client with read permissions only and just expose the client secret in your webapp.
That’s the point, I wasn’t planning on using a backend.
Exposing the client secret inside the client is equivalent to giving read/write access to all the DB.
It means I have to make a backend which generates an api key and redeploy my static website with that kay inside everymonth. Way more than 20 lines 
But what if you added an option to open selected datas in read-only, so they wouldn’t require an access token to get ?
From my side, I’ll think about making a backend…
Why do you have to generate a new api key manually?
Squidex distinguishes between clients and api tokens. A client is valid forever and you acquire a token in the name of a client. So you can write a helper method like this in your server or frontend:
var cache = new MemoryCache();
public string MakeRequest(string url)
{
var accessToken = cache.GetOrAddAsync("Token", TimeSpan.FromDays(20), () => {
return GetAccessToken();
});
var response = MakeRequest(url);
if (response.StatusCode == 401)
cache.Remove("Token");
throw ...;
}
return response.ReadAsString();
}
If you create a client you can also define the role. The default role Reader has permissions to read all contents and assets, but cannot create, update or delete content or assets.
Futhermore you can create a custom role, e.g. if you only need read permissions to articles, and blog, you can give this role the following permissions:
schemas.blog.readschemas.articles.readMore about permissions in the docs: https://docs.squidex.io/concepts/permissions
My client is my frontend website. I don’t want it to have to renew its token. Since its client-side JS only, it means it has to get a token for every visitor.
If I manage to generate the token server side, it would be no problem, but currently I can’t use squidex without another backend to handle the client token
Sry, I cannot help you more at the moment. Personally I do not see a big problem to get the token in the frontend. It is a small performance impact for sure, but I think it is acceptable.
So If my website has 100K unique users/browser per month, it will generate 100k token, right ? That seems a lot 
From which perspective? The tokens are not stored anywhere, they are just generated. And it is only one token every 30 seconds
+1 for public access options.
I would like this to behave like a file server, if configured to do so. Auth should be optional, not required.
I am also making a front end website.
All content should be accessible from DOM elements without requiring auth at all.
In my use case, squidex is used for two use cases:
Auto deploy and deliver testable websites internally, many versions of the website deployed temporarily until the merge request is approved. There is no need for auth here, it’s just adding complexity. I’d like to just use file URL’s directly, as if it were a standard file server. I can work around this limitation, but doing so does not gain me anything. A simple option to disable auth for public read would be preferred.
The second use case it to deploy Squidex content public for a prod release, in which case I will dump the contents into a file server ( with CloudFlare ) to do the hosting. Squidex will not be involved in the final website release.
As you can see, my use case does not involve OAuth at all for reading, only for editing. In fact, oAuth is actually getting in the way because it’s preventing me from being able to use DOM SRC attributes directly.
I will see what I can do. It is very unlikely that I will ever allow no-token but I see the need for a simpler token validation.
I guess I’m dreaming too big when wanting something like:
<img src="https://cloud.squidex.io/api/assets/my-app/7ba1eb41-4943-442e-b033-dac4893dbd6c" />
to ‘just work’ ?
I’d like to understand the reasoning behind not allowing this, but I couldn’t find anything in the documentation that described why this is required.
Again, thank you for all your hard work.
One of the reasons is just technical. You have to hook into the authentication system and anonymous authentication is kind of a different path that allows that and could open several vulnerabilities. So far Squidex permissions are always positive, you need a permission to do something and this makes it easy to reason about from the code perspective.
The other reason is a UI perspective, somewhere you need to define the permissions and API tokens are the right place for it I think.
But while thinking about this while writing the answer, we could potentially integrate something like an anonymous API token that has all permissions and just no token. I will think about it.
This has been implemented now. A client has a new flag “allow anonymous”. If no access token is defined the permission of the first client with this flag is returned used to define the permissions.
it is not deployed to the cloud yet.
It is deployed now …