Keycloak as Federated Identity Provider

**Describe your question/**
I try to configure Keycloak as "Federated Identity Provider" and use it in Authentik.
The initial login works, the user is sent to Keycloak to login and sent back to Authentik and is successfully logged-in:

- (1) Go to Authentik login page, click on federation button
- (2) After redirect to Keycloak login with Keycloak user credentials
- (3) After redirect to redirect URL to Authentik the user is created in the backend of Authentik and logged-in successfully

Problem:

The user cannot log-in a second time, as the user is not recognized by Authentik anymore:

The procedure will work as follows:

- (1) Go to Authentik login page, click on federation button -- OK!
- (2) After redirect to Keycloak login with Keycloak user credentials -- OK!
- (3) After redirect to redirect URL to Authentik the user is created in the backend of Authentik and logged-in successfully - NOK, user receives 403, "not authenticated"

The event log in Authentik does _not_ show any login attempts for the original user that was logged-in / created in the first attempt. The user is not recognized by Authentik.

Our assumption is a a missing ID/attribute mapping to identify the user after its first login. How is Authentik doing this? Which attributes is it using or which ones do need to be mapped and where?

**Relevant info**
Latest version of Authentik and Keycloak

**Screenshots**
There is nothing much to show here, as there is no user interface in Authentik that describes/configures user identification information. We are trying to follow the user guide here: https://docs.goauthentik.io/docs/users-sources/sources/social-logins/azure-ad/

**Logs**
The logs show "403" messages, no errors are reported.

**Version and Deployment (please complete the following information):**

- authentik version: test with 2024.8, 2025.2
- Deployment: docker-compose

**Additional context**
We attempted to understand the user-attribute mapping in the sample for AZURE-AD. We assume that the "required_fields_map" in the sample script linked above (see Screenshots) is used to identify the user that is returned by Keycloak. Is there any other information about the mechanics/identification-process of the returned user that the federated provider returns?

Start with the Azure-AD social-login user guide and sample referenced in the issue, then reproduce the first and second Keycloak login using authentik 2024.8 or 2025.2 with Docker Compose. Trace the returned user's attributes and mapping behavior; done means the same user is recognized and authenticated on the second login without a 403.

Written by the indexing model from the issue text.