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

+1 To the user info toggle for mappers On 1 July 2016 at 11:12, Thomas Darimont <thomas.darimont(a)googlemail.com&gt; 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-mapp... > relevant commit: > > https://github.com/thomasdarimont/keycloak/commit/eb25e72060f75a00afd188f... > > Cheers, > Thomas > > 2016-07-01 9:53 GMT+02:00 Thomas Darimont <thomas.darimont(a)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(a)gmail.com&gt;: >> >>> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user >