[keycloak-dev] html app, node api server and keycloak

Luke Holmquist lholmqui at redhat.com
Fri Apr 29 14:18:23 EDT 2016


On Fri, Apr 29, 2016 at 2:03 PM, Luke Holmquist <lholmqui at redhat.com> wrote:

>
>
> On Fri, Apr 29, 2016 at 2:01 PM, gambol <gambol99 at gmail.com> wrote:
>
>> If I'm not mistaken the access type would be 'public' since you can't
>> secure the client secret (
>> http://stackoverflow.com/questions/14574846/client-authentication-on-public-client)
>> ...
>>
> Yeah, i think that was always the plan for the html app, possibly also
> with the implicit grant flow
>
>> In regard to the API, there's technically no need to speak to keycloak to
>> verify the token, given the jwt is signed by the provider. So assuming the
>> library your using on the API pulls the jwt public keys from keycloak
>> (openid discovery URL perhaps) or has it hardcoded, you have everything you
>> need to verify the the token.
>>
> It looks like though with the public client, there is no access to the
"credentials" tab that would allow me to switch on sign jwt's  or are you
talking about something completely different?

> Rohith
>> crap, forget the subject line
>>
>> On Fri, Apr 29, 2016 at 1:09 PM, Luke Holmquist <lholmqui at redhat.com>
>> wrote:
>>
>>> I have a use case, that i think could be pretty common,  but i'm not
>>> entirely sure how to setup it up.
>>>
>>> The following is a little bit of a thought dump, so pardon me if i
>>> ramble a little bit.
>>>
>>>
>>> There are i think 3 components involved here:
>>>
>>> 1. a pure HTML/JS web app
>>>
>>> 2. A node.js REST  API server
>>>
>>> 3. Keycloak server
>>>
>>>
>>> The app in this case, would not be served by the node server or the KC
>>> server(wildfly), but with something like nginx(or even something like
>>> 'python simpleHTTPServer')
>>>
>>> Basically the flow would be something like this[1]:
>>>
>>> The web app, using the js adapter, authenticates against the KC server.
>>>
>>>  Now the web app would like to call the node API server(a restricted
>>> endpoint) to get some data
>>>
>>> The web app probably adds the token stuff that it got from KC during
>>> it;s login to the request to the node server
>>>
>>> ***This next part is where i'm getting a little confused, i'm aware that
>>> code to do this might not be written yet****
>>>
>>> I'm thinking the node server takes the token from the web app request,
>>> and would hit an endpoint on the KC server to make sure that token is
>>> valid.
>>>
>>> If things go ok, then node server returns the data.
>>>
>>> I've seen the recent post on doing token introspection and abstracj was
>>> nice enough to make that into a gist,
>>> https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061
>>>
>>> but this would also mean the web client access_type would need to be
>>> confidential(which i don't think is secure for a web app) to make a service
>>> account that the node server could use to do the token introspection.
>>>
>>> I was thinking of maybe creating a client also for the node server, but
>>> is it possible for 1 client to lookup/validate tokens from another client.
>>>
>>>
>>> Perhaps i'm thinking about this all wrong too, which is very possible.
>>>
>>> In this example there is only 1 node api server,  but there could be
>>> multiple node/go/rust/<insert cool kid tech here> servers too
>>>
>>>
>>>
>>> Any guidance would be appreciated and sorry for the ramble
>>>
>>> -Luke
>>>
>>>
>>>
>>>
>>>
>>>
>>> [1]
>>> https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROYQ2iWtU/edit
>>>
>>> _______________________________________________
>>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/39d527a4/attachment-0001.html 


More information about the keycloak-dev mailing list