How to set up Authorization Code flow with IDP (Keycloak) and custom SPA

Support
1

Hello Sebastian,

We are developing an application and use Squidex as CMS. End users should be able to execute CRUD functions on the CMS in a custom React app. We want to secure Squidex and the React app with Keycloak and use it for authentication.

In Squidex we used the OIDC config for this and it works wonderfully for Squidex. We have also implemented authentication in our frontend and it runs with Keycloak.

The problem now is that we thought we were using the Authorisation Code Flow and could use the access_token, which we get from the Keycloak in the frontend, to access the Squidex and retrieve authenticated resources there, etc…
Unfortunately, we always get a 401 Unauthorised back. We have tried a few things in the meantime but can’t get it to work.

Hence the questions: Does Squidex support this at all? Are we making a mistake? And how can we implement this? It is important that users are identified individually from our frontend and that each CRUD operation etc. can be clearly assigned.

Many thanks in advance!
Jochen

2

Users in Squidex do not get the access_token from keycloak, but from the internal identity system.

Therefore you cannot use the access_token that you got from key_cloak. I would not mix up the Squidex users and the end users. If you need tracking I would create a field for that and pass that over to Squidex content.

3

Good morning Sebastian,

Thank you for your response, even though it’s not quite what I was hoping to hear. Could you please elaborate on your explanation? As I understand it:

  1. We create a client for our frontend to enable access to the Squidex API.
  2. Users log into the frontend via Keycloak and receive a user ID.
  3. For each necessary schema, we create an “externalUserID” or similar, and we send this with every call as regular data.

Is this understanding correct?

4

Hi,

usually you have three artifacts here:

  1. The Identity Server (e.g. Keycloak) provides authentication mechanisms and access tokens.
  2. The Application provides the interface for the user and authorizes the user using redirects.
  3. The Backend / Resource is a resource and the access token is acquired with scopes in mind to get access to the backend.

By default, Squidex backend acts as Identity Server, backend and Application (frontend). When you connect an external identity, this is just an external authentication provider for Squidex that is used by the integrated identity server.

Theoretically you can replace the internal identity server in Squidex, but it is not possible without forking.

Then the squidex frontend would be a registered application in Keycloak and the backend would be a registered backend / resource in Keycloak. But it does not make your live easier, only if the users would interact with Squidex directly. If you have an API in between you also need to ensure that you pass the user identity token over. Furthermore it introduces security challenges because your end users have now access to Squidex and can do whatever you allow them to do.

Therefore I would not do that.

Yes, this is correct.

5

Thank you for the detailed answer!

I have been thinking about an alternative solution. Could we use Squidex’s internal identity server for all our users and only use Keycloak or Azure as external authentication providers?

I had already tried to configure everything accordingly, but got the error that the redirect_uri is not correct/allowed. Can this be configured or is it hard-coded? I haven’t found anything about this in the documentation and example configs.

Would that be possible?

6

You would have to fork the code to do thjat. I was thinking about users before: New Feature "Users" - #4 by Sebastian

You could read that and we could have a talk over hangout.