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

[Stian Thorgersen]

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?


>
> On Thu, Apr 5, 2018 at 12:31 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > One important thing I can think of is if we add support for JWEs we need
> to
> > make sure this thing doesn't return token details.
> >
> > On Thu, 5 Apr 2018, 17:09 Pedro Igor Silva, <psilva at redhat.com> wrote:
> >
> >> Nope :)
> >>
> >> On Thu, Apr 5, 2018 at 12:03 PM, Stian Thorgersen <sthorger at redhat.com>
> >> wrote:
> >>
> >>> I can see it being helpful in production for debugging purposes. It may
> >>> also be helpful for application developers that are trying to figure
> out
> >>> what's going on in their apps.
> >>>
> >>> Do you have any actual concerns about it being exposed rather than just
> >>> because it's more stuff to expose ;)
> >>>
> >>> On 5 April 2018 at 16:58, Pedro Igor Silva <psilva at redhat.com> wrote:
> >>>
> >>>> To avoid additional endpoints that are not really part of the core
> >>>> functionality. For demo and testing this is very helpful but in
> production
> >>>> you don't want the server serving such requests and consuming
> resources.
> >>>>
> >>>> Treat as a "feature" seems more reasonable for me instead of always
> have
> >>>> it available.
> >>>>
> >>>> On Thu, Apr 5, 2018 at 11:47 AM, Stian Thorgersen <
> sthorger at redhat.com>
> >>>> wrote:
> >>>>
> >>>>> Just to add - we can easily make it a feature that can be
> >>>>> enabled/disabled through the profile stuff, but was just curious to
> why you
> >>>>> thought it would be needed to disable it.
> >>>>>
> >>>>> On 5 April 2018 at 16:45, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >>>>>
> >>>>>> Why?
> >>>>>>
> >>>>>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> >>>>>>
> >>>>>>> Although very helpful, people may want to disable this when in
> >>>>>>> production.
> >>>>>>>
> >>>>>>> On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <
> sthorger at redhat.com
> >>>>>>> > wrote:
> >>>>>>>
> >>>>>>>> I added an example token validator endpoint that I needed for some
> >>>>>>>> demonstration purposes. Question would this be useful to add
> >>>>>>>> directly to
> >>>>>>>> Keycloak?
> >>>>>>>>
> >>>>>>>> It provides a simple form where you can paste in the base64 token.
> >>>>>>>> It will
> >>>>>>>> then output the header, claims and whether or not the token is
> >>>>>>>> valid. It
> >>>>>>>> uses realm keys to verify the signature so you don't have to paste
> >>>>>>>> that in
> >>>>>>>> manually (like you do on jwt.io).
> >>>>>>>>
> >>>>>>>> For those to lazy to try it out I've attached a screenshot.
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> keycloak-dev mailing list
> >>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Bill Burke
> Red Hat
>