Hello Brian,

I gave this a quick spin - I introduced an additional option that allows to configure whether a claim from a 
client mapper should be included in userinfo or not. 
With that in place one can now control whether a claim should be contained in the access-token, id-token or userinfo
which helps to keep access-tokens lean.

For the sake of simplicity I only added support for controlling user attributes but I think this could be a useful 
for other mappers as well.

Branch is here:
relevant commit:


2016-07-01 9:53 GMT+02:00 Thomas Darimont <thomas.darimont@googlemail.com>:
Hello Brian,

I gave this a spin (with 1.9.x and master) and I think that currently the only way to extend the information in the 
userinfo endpoint is by defining a custom mapper and register that for the client you use to get the
The protocol mappers of this client will be used for the userinfo endpoint. However the downside of this approach is that 
this information is now also added to the access-token which you wanted to avoid.

It would be great of one had an additional switchable option for custom protocol mappers like "include in userinfo".
With this enabled one could control very explicitly what should go where.

I added a small curl command sequence below that can be used for testing.


# Setup
CURL_OPTS="-k -v --noproxy"

# Step 1 Request Tokens for credentials
   curl $CURL_OPTS -X POST \
        -H "Content-Type: application/x-www-form-urlencoded" \
        -d "username=$KC_USERNAME" \
        -d "password=$KC_PASSWORD" \
        -d 'grant_type=password' \
        -d "client_id=$KC_CLIENT" \
        -d "client_secret=$KC_CLIENT_SECRET" \
        "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" \
    | jq . 

# Step 2 Split tokens
KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token)
KC_ID_TOKEN=$(echo $KC_RESPONSE| jq -r .id_token)
KC_REFRESH_TOKEN=$(echo $KC_RESPONSE| jq -r .refresh_token)

# Step 3 (Debug) Show all keycloak env variables
set | grep KC_*

# Step 4 Access Keycloak User Info
curl $CURL_OPTS \
     -X POST \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "access_token=$KC_ACCESS_TOKEN" \
   "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/userinfo" | jq .

# Step 5 Define a new protocol mapper for the client test-client in the admin-console
# via clients -> test-client -> mappers -> new -> as an example map a custom user attribute -> add to access token 
# After that a request to the userinfo endpoint will show your custom attribute.

# Step 6 Access Keycloak User Info
curl $CURL_OPTS \
     -X POST \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "access_token=$KC_ACCESS_TOKEN" \
   "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/userinfo" | jq .

2016-06-30 16:41 GMT+02:00 Brian Watson <watson409@gmail.com>:
Hi all,

Keycloak version: 1.9.8

Here is my use case: I want to keep the access token JWS as lean as possible, only containing user roles and a few custom claims I have added. I want no PII in the access token. However, I would like my internal services to obtain the full user profile (name, email, etc...) from the OIDC "/userinfo" endpoint. Unfortunately, I can only seem to obtain the "sub" claim and the few custom claims that already exist in the access token. I don't see any support for adding scope values to the request.

Is there any way to accomplish what I would like, or any other ways of obtaining this info that I may be missing?

Thanks in advance

keycloak-user mailing list