Dropping "bearer-only"?

[Stian Thorgersen]

The new admin console designs are dropping the "bearer-only" option for a client:

https://marvelapp.com/prototype/908c3c3/screen/72041413

This makes perfectly sense to me, as a "bearer-only" client is really only a client that doesn't leverage any of the OAuth flows.

[Julien.Pliss...@cdiscount.com]

If I understand correctly, not checking any OAuth flow box in this
design would achieve the same thing as the old 'bearer-only' setting?
It would make sense then, and would be more intuitive than the previous
way.

--
Julien Plissonneau Duquène

[Stian Thorgersen]

On Wed, 3 Mar 2021, 11:20 Julien.Plissonneauduquene via Keycloak Dev, <keyclo...@googlegroups.com> wrote:

If I understand correctly, not checking any OAuth flow box in this
design would achieve the same thing as the old 'bearer-only' setting?
It would make sense then, and would be more intuitive than the previous
way.

Exactly. When the bearer only option was introduced in the early days of Keycloak it made more sense as we didn't have service account, authz services, token introspection endpoint, etc. So a bearer only was just a client with some client roles.

--
Julien Plissonneau Duquène

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/8dde272fcde89832c7400aaa5127d7eb00a4f55e.camel%40cdiscount.com.

[Marek Posolda]

+1

One minor thing to consider: Since bearer-only client is not able to have it's own sessions, we hide lots of tabs of this client in the admin console (Client scopes, mappers, sessions etc). Will be good to still hide those tabs in case that no flow is enabled for the client.

Marek

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAJgngAfE4zwVtpTHOZy7QAyz7ta0QCtnRfo8TEKkMf0JVnaK8Q%40mail.gmail.com.

[Pedro Igor Craveiro e Silva]

+1. Shall we keep the bearer-only option in adapters?

I see they might be useful there to configure whether the application should only support bearer token authorization.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/58765e65-1b41-598d-50db-8bc5afbff802%40redhat.com.

[Stian Thorgersen]

On Wed, 3 Mar 2021 at 14:44, Pedro Igor Craveiro e Silva <pigor.c...@gmail.com> wrote:

+1. Shall we keep the bearer-only option in adapters?

I see they might be useful there to configure whether the application should only support bearer token authorization.

Should have been the other way around, but yes we should just keep the option there. When exporting client config we can just check if any oauth flows are enabled and if they aren't set bearer-only to true. 

[Stan Silvert]

On 3/3/2021 7:51 AM, Marek Posolda wrote:

+1

One minor thing to consider: Since bearer-only client is not able to have it's own sessions, we hide lots of tabs of this client in the admin console (Client scopes, mappers, sessions etc). Will be good to still hide those tabs in case that no flow is enabled for the client.

Marek

In the database, we have boolean values for PUBLIC_CLIENT and BEARER_ONLY.

In the new admin console, do we need to calculate these values and still save them with the client?  (We no longer have the "Access Type" field in the new UI)

We can do it, but it gets a little weird because the values of  PUBLIC_CLIENT and BEARER_ONLY would be calculated based on several other UI fields.

On 03. 03. 21 11:40, Stian Thorgersen wrote:

On Wed, 3 Mar 2021, 11:20 Julien.Plissonneauduquene via Keycloak Dev, <keyclo...@googlegroups.com> wrote:

If I understand correctly, not checking any OAuth flow box in this
design would achieve the same thing as the old 'bearer-only' setting?
It would make sense then, and would be more intuitive than the previous
way.

Exactly. When the bearer only option was introduced in the early days of Keycloak it made more sense as we didn't have service account, authz services, token introspection endpoint, etc. So a bearer only was just a client with some client roles.

--
Julien Plissonneau Duquène

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/8dde272fcde89832c7400aaa5127d7eb00a4f55e.camel%40cdiscount.com.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAJgngAfE4zwVtpTHOZy7QAyz7ta0QCtnRfo8TEKkMf0JVnaK8Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/58765e65-1b41-598d-50db-8bc5afbff802%40redhat.com.