[keycloak-user] Obtaining full profile from "userinfo" endpoint

Stian Thorgersen sthorger at redhat.com
Fri Jul 1 05:18:32 EDT 2016


+1 To the user info toggle for mappers

On 1 July 2016 at 11:12, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> 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:
>
> https://github.com/thomasdarimont/keycloak/tree/poc/KEYCLOAK-XXX-use-mapper-only-for-userinfo-endpoint
> relevant commit:
>
> https://github.com/thomasdarimont/keycloak/commit/eb25e72060f75a00afd188fc3b2c242e7b21aa7f
>
> Cheers,
> Thomas
>
> 2016-07-01 9:53 GMT+02:00 Thomas Darimont <thomas.darimont at 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
>> access-token.
>> 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.
>>
>> Cheers,
>> Thomas
>>
>> # Setup
>> KC_REALM=acme-test
>> KC_USERNAME=tester
>> KC_PASSWORD=test
>> KC_CLIENT=test-client
>> KC_CLIENT_SECRET=3ee678ac-b31b-4bb6-80fa-5f25c7817bf0
>> KC_SERVER=192.168.99.1:8080
>> KC_CONTEXT=auth
>> CURL_OPTS="-k -v --noproxy 192.168.99.1"
>>
>> # Step 1 Request Tokens for credentials
>> KC_RESPONSE=$( \
>>    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 at 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
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160701/851d6036/attachment.html 


More information about the keycloak-user mailing list