[keycloak-dev] Credentials in javascript adapter
Stian Thorgersen
sthorger at redhat.com
Mon Nov 18 07:04:53 EST 2019
My preference is a new client for the new account console, with the current
client being used for the old server-side account console and roles. It is
safer and has less potential of having any side-effects now and in the
future.
On Mon, 18 Nov 2019 at 09:51, Stian Thorgersen <sthorger at redhat.com> wrote:
> The only place that would need to change is the client used in keycloak.js
> by the new account console, so should be a one-line change. The other
> things should stay as is since those are related to the roles.
>
> It would probably work to change to public for now though. This will need
> to change in the future regardless as we should remove keycloak.js from
> account and admin consoles, since they are colocated with the REST APIs
> they should use cookies, not tokens in-mem.
>
> On Sun, 17 Nov 2019 at 21:12, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 15. 11. 19 21:10, Stan Silvert wrote:
>> > On 11/15/2019 12:15 PM, Stan Silvert wrote:
>> >> On 11/15/2019 9:05 AM, Stian Thorgersen wrote:
>> >>> The account console should be a confidential client as it is there for
>> >>> the old account console.
>> >>>
>> >>> Instead you should create a new client for the new account console.
>> >> Sigh. That's definitely not the answer I was hoping for.
>> > So this is looking like a very big change. There is code all over the
>> > place assuming that the client id is "account". I really don't want to
>> > hack up our code everywhere to make it point to a different client
>> > definition every time the Theme is set to "keycloak-preview". It's more
>> > than just changing the return value of
>> > Constants.ACCOUNT_MANAGEMENT_CLIENT_ID.
>> >
>> > Additionally, any changes I make would need to revert back once new
>> > account console becomes standard. So changes that only support tech
>> > preview don't make a lot of sense.
>> >
>> > I see two less-invasive solutions:
>> > 1) Allow the old account console to be a public client.
>> > 2) Document that "tech preview" users should go to Client -> account.
>> > Then change the Access Type to "public".
>>
>> The old account console is using a bit different flow than normal OIDC
>> confidential clients. It relies on the fact that it is deployed on same
>> server as Keycloak and it just uses the Keycloak cookies like
>> KEYCLOAK_IDENTITY cookie for the authentication. AFAIK it doesn't use
>> any OIDC backchannel requests, which require client authentication.
>>
>> In other words, I think that changing old account console to public
>> client shouldn't break anything. So IMO solution 1 will just work.
>>
>> However I am not 100% sure. It will be good to run the testsuite after
>> changing the "account" client to public and do some more checks of
>> sources. But AFAIK I can't recall any reason why it won't work.
>>
>> Marek
>>
>>
>> >
>> >>> On Fri, 15 Nov 2019 at 14:03, Stan Silvert <ssilvert at redhat.com
>> >>> <mailto:ssilvert at redhat.com>> wrote:
>> >>>
>> >>> On 11/7/2019 7:46 AM, Stian Thorgersen wrote:
>> >>> > It might be there from the early days when we didn't have
>> public
>> >>> clients.
>> >>> > I'd probably just keep it in case someone is using it with a
>> >>> confidential
>> >>> > client as removing it would break it for them. Although
>> strictly
>> >>> speaking
>> >>> > you shouldn't use a confidential client with a client-side
>> app.
>> >>> There is something else left over from when we didn't have
>> public
>> >>> clients. The account console is still a confidential client.
>> >>>
>> >>> With this latest change in the javascript adapter, the new
>> account
>> >>> console is broken. (Both old and new account console use the
>> same
>> >>> client definition)
>> >>>
>> >>> Does anyone have an issue with changing the (old and new)
>> account
>> >>> console to a public client?
>> >>>
>> >>> >
>> >>> > On Thu, 7 Nov 2019 at 07:42, Michal Hajas <mhajas at redhat.com
>> >>> <mailto:mhajas at redhat.com>> wrote:
>> >>> >
>> >>> >> Hello,
>> >>> >>
>> >>> >> in Javascript adapter we have a possibility to configure a
>> >>> client secret
>> >>> >> [1] in order to use Basic authorization for requests for
>> token
>> >>> endpoint
>> >>> >> [2]. I haven't found any information in docs about it and I
>> don't
>> >>> >> understand why we have it there as public clients don't have
>> >>> secrets. Is
>> >>> >> this useful in some scenarios or we should remove it?
>> >>> >>
>> >>> >> Michal
>> >>> >>
>> >>> >> [1]
>> >>> >>
>> >>> >>
>> >>>
>> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L882
>> >>> >> &
>> >>> >>
>> >>> <
>> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L882&
>> >
>> >>> >>
>> >>> >>
>> >>>
>> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L866
>> >>> >>
>> >>> >> [2]
>> >>> >>
>> >>> >>
>> >>>
>> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L617
>> >>> >> &
>> >>> >>
>> >>> <
>> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L617&
>> >
>> >>> >>
>> >>> >>
>> >>>
>> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L732
>> >>> >> _______________________________________________
>> >>> >> keycloak-dev mailing list
>> >>> >> keycloak-dev at lists.jboss.org <mailto:
>> keycloak-dev at lists.jboss.org>
>> >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>> >>
>> >>> > _______________________________________________
>> >>> > keycloak-dev mailing list
>> >>> > keycloak-dev at lists.jboss.org <mailto:
>> 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
>> >
>> > _______________________________________________
>> > 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
>
>
More information about the keycloak-dev
mailing list