[keycloak-dev] Token validator endpoint (for humans)

[Bill Burke]

On Fri, Apr 6, 2018 at 12:17 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>
> On 6 April 2018 at 04:39, Bill Burke <bburke at redhat.com> wrote:
>>
>> On Thu, Apr 5, 2018 at 3:46 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> > This endpoint is meant to just return exactly what is in the token so a
>> > human can quickly copy/paste it to see what's in the base64 token.
>> > However,
>> > if it's JWE encrypted and should be opaque, then it obviously shouldn't
>> > decrypt the details and return it.
>> >
>> > As long as the token isn't JWE and just a JWT then the human could just
>> > as
>> > well have decoded the token himself, but this is just a tool to help
>> > doing
>> > that ;)
>> >
>> > On 5 April 2018 at 19:08, Bill Burke <bburke at redhat.com> wrote:
>> >>
>> >> If your service is receiving a valid active token, why does it matter
>> >> if it is a valid JWE or not?   Related to this is that protocol
>> >> mappers allow you to define how an access token, id token, AND the
>> >> user info service looks like.  Couldn't your endpoint just use the
>> >> user info output?  Then you are sure that you are not leaking
>> >> anything.
>> >>
>> >> BTW, we'll need such an "open endpoint" when reference tokens come in.
>> >
>> >
>> > Can you elaborate on that?
>> >
>>
>> public clients that have reference tokens need to validate them and
>> get user information from them.  Maybe that's just the user info
>> service though.
>
>
> That's actually a rather interesting problem just there. One reason folks
> want to have access tokens is that they don't want sensitive information to
> leave the organization boundary. As such we'd have to be really careful
> about what information is exposed and probably also somehow make it
> configurable.
>

My thought was that developers would just use the user info endpoint
to validate reference tokens.  We already have control, per client, of
what the user info service spits out.

FYI, kubernetes/openshift need a different endpoint like this, but
only username and group membership is outputted.  This is why I need
to add "groups" to client scope.



-- 
Bill Burke
Red Hat