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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Forgot the link: https://github.com/stianst/keycloak-experimental/tree/ master/token-validation Hm... need to tune the mailing list so it's possible to include images. I thought it already was. On 5 April 2018 at 15:17, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > > > On 2018-04-05, Stian Thorgersen 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). > > Where is the link to give it a try? > > > > > > For those to lazy to try it out I've attached a screenshot. > > It seems like your screenshot was blocked by the mailing list. > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > > abstractj >

+1 Question, how are you adding this endpoint? Under ../protocol/oidc? The kubernetes integration needs a similar validation endpoint that outputs a document that kubernetes consumes. What I did is create an entirely new protocol. Maybe a protocol extension endpoint would be better? Object createExtensionEndpoint(String providerId) The returned Object would be a JAX-RS sub resource. Then the base endpoint would be .../protocol/oidc/extensions/{provider-id} On Thu, Apr 5, 2018 at 8:04 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat

I'll just switch to using that probably. On Thu, Apr 5, 2018 at 9:48 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > We already have a realm resource provider which adds directly under realm > (/auth/realms/<realm name>/<resource provider id>). See > https://github.com/stianst/keycloak-experimental/blob/ master/token-validation/src/main/java/org/keycloak/experimental/token/ TokenValidatorFactory.java#L31. > > The URL for this thing is: /auth/realms/master/token-validator > > Perhaps we could extend the realm resource provider to allow not just adding > directly under realms, but under any arbitrary path? Not sure if RestEasy > allows that though. > > On 5 April 2018 at 15:41, Bill Burke <bburke(a)redhat.com&gt; wrote: >> >> +1 >> >> Question, how are you adding this endpoint? Under ../protocol/oidc? >> >> The kubernetes integration needs a similar validation endpoint that >> outputs a document that kubernetes consumes. What I did is create an >> entirely new protocol. Maybe a protocol extension endpoint would be >> better? >> >> Object createExtensionEndpoint(String providerId) >> >> The returned Object would be a JAX-RS sub resource. >> >> Then the base endpoint would be .../protocol/oidc/extensions/{ provider-id} >> >> >> >> On Thu, Apr 5, 2018 at 8:04 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; >> 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(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> -- >> Bill Burke >> Red Hat > > -- Bill Burke Red Hat

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Why? On 5 April 2018 at 16:23, Pedro Igor Silva <psilva(a)redhat.com&gt; 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(a)redhat.com&gt; > 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >

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(a)redhat.com&gt; 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(a)redhat.com&gt; wrote: > >> Why? >> >> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva(a)redhat.com&gt; 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(a)redhat.com&gt; >>> 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> >

Nope :) On Thu, Apr 5, 2018 at 12:03 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; >> 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(a)redhat.com&gt; wrote: >>> >>>> Why? >>>> >>>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva(a)redhat.com&gt; 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(a)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(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> >>>> >>> >> >

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.

On Thu, Apr 5, 2018 at 12:31 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; 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(a)redhat.com&gt; wrote: > >> Nope :) >> >> On Thu, Apr 5, 2018 at 12:03 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; >> 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>> 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(a)redhat.com&gt; wrote: >>>>> >>>>>> Why? >>>>>> >>>>>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva(a)redhat.com&gt; 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(a)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(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat

On Thu, Apr 5, 2018 at 3:46 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; 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&gt; 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.

Bill

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(a)redhat.com&gt; wrote: > Nope :) > > On Thu, Apr 5, 2018 at 12:03 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>> 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(a)redhat.com&gt; >>>> wrote: >>>> >>>>> Why? >>>>> >>>>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >

Really nice ! I just gave it a try and it works perfectly. I was thinking that we could maybe add an extra @POST endpoint that returns a json object so that third parties could integrate with this service, wdyt ? On Thu, Apr 5, 2018 at 2:04 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >