On 6 April 2018 at 04:39, Bill Burke <bburke(a)redhat.com> wrote:
On Thu, Apr 5, 2018 at 3:46 PM, Stian Thorgersen
<sthorger(a)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(a)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.
Bill