We are managing content with a self-hosted Squidex instance.
Currently our mobile app (and soon a web app) authenticates against our Identity Server instance. We would like that the returned token to also provide auth for making API calls to retrieve Squidex content.
We’ve already connected our Identity Server to our Squidex install so you can login with OIDC and access the admin portal. But our mobile app users will only need auth against the content API.
One other important note: we will have several Squidex “apps”. The API permission (which we’ll limit to read-only) should allow that user’s token to access the content from any app. (Though I imagine we’d have to extend the Squidex platform to do this.)
this is only possible if you also manage the Squidex users in your identity server.
Right now the users are managed in Squidex (which is using Identity Server anymore). When you login to Squidex a redirect is done to your Identity Server (just IdSrv from now on) and then the user is created in the Squidex database.
What you need is to replace the whole Identity System in Squidex with your IdSrv. Then Squidex is just an normal API (aka Resource) and you can also define the permissions as you want.
This is great information and points us in the right direction. We’ve been digging into the Squidex code over last few days, and it’s becoming more clear what we need to do.
Our content is not sensitive, but we just don’t like the idea of our content API allowing anon access. So another path we’re looking at is modifying the permissions check so that any validated token (from our Identity Server) would be granted read access via API. Would something like this allow us to leave most of the Squidex auth in place and minimize our efforts? If you have thoughts on this approach, please let us know.