Is there a name for "ROPC with a public client"?

[mag...@therning.org]

The grant type described at [1] is against an internal client,
since
only internal clients have client secrets. However, there is a
variant
that can be run against a public client but it doesn't seem to be
documented anywhere. Does it have a name?

An example request looks like this:

```
curl \
-d "client_id=myclient" \
-d "username=user" \
-d "password=password" \
-d "grant_type=password" \
"http://localhost:8080/realms/master/protocol/openid-connect/token"
```

and it results in a response with both 'access_token' and
'refresh_token'.

/M

[1]:
https://www.keycloak.org/securing-apps/oidc-layers#_resource_owner_password_credentials_flow

--
Magnus Therning OpenPGP: 0x927912051716CE39
email: mag...@therning.org
@mag...@mastodon.technology http://magnus.therning.org/

If you can explain how you do something, then you're very very bad
at
it.
— John Hopfield

[Alexander Schwartz]

Hi Magnus, 

It has the same name and semantics, there is no difference if it is a public or confidential client except for the credentials being sent. 

Best,

Alexander

--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/keycloak-user/87v7p3bxw7.fsf%40therning.org.

--

Alexander Schwartz, RHCE

He/Him

Principal Software Engineer, Keycloak Maintainer

Red Hat - Germany remote

asch...@redhat.com   

Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany 
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

[mag...@therning.org]

Alexander Schwartz <asch...@redhat.com> writes:

> Hi Magnus,
>
> It has the same name and semantics, there is no difference if it
> is a public or confidential client except for the credentials
> being sent.

Isn't there a crucial difference in that the user credentials are
sent straight to the Keycloak server with a public client, rather
than to a confidential client that then pass them on to Keycloak?

/M

Time is a great teacher, but unfortunately it kills all its
pupils.
— Hector Louis Berlioz

[Alexander Schwartz]

Hi Magnus,

Even when one might assuming a single page application with a public client the browser, where the browser sends the request to Keycloak, it is not so much of a difference to the user: 

They would need to hand the username and the password to an application that is running in the browser, that they should actually not really trust with their password. The user can't really tell what the application is doing with that username and password. The only place they should trust to put in the username and password would be the official login page of your Keycloak instance. 

Best,

Alexander

[mag...@therning.org]

Alexander Schwartz <asch...@redhat.com> writes:

> Hi Magnus,
>

> Even when one might assuming a single page application with a
> public
> client the browser, where the browser sends the request to
> Keycloak,
> it is not so much of a difference to the user:
>
> They would need to hand the username and the password to an
> application that is running in the browser, that they should
> actually
> not really trust with their password. The user can't really tell
> what
> the application is doing with that username and password. The
> only
> place they should trust to put in the username and password
> would be
> the official login page of your Keycloak instance.

True, I suppose a user would trust the login application served by
the
keycloak service a bit more than the application requiring the
token.

However, in this case I'm actually _not_ thinking of a scenario
involving a web site at all.

At work we offer a web API to customers that they need a token to
access. In the past we've handed out client credentials to them so
they
can use that flow to get a token.

We've recently switched to Keycloak and I've been thinking about
changing this. From what I understand there's really only one
drawback
to asking our customers to ROPC against a public client for
machine2machine access

- they need to provide us with a dedicated email address.

At the same time there are several advantages

- we can't see their password (we can see client credentials)
- we've enabled password reset by users, so they can change their
password (client credentials need to be reset by us)
- finally an advantage that's purely for us: we don't need to
manage
100s of client credentials on top of the 1000s of users

Yes, we probably should do some sort of API keys instead, but
Keycloak
doesn't seem to offer that so we'd like to make that improvement
later,
if possible.

/M

"I am so amazingly cool you could keep a side of meat in me for a
month. I am so hip I have difficulty seeing over my pelvis."

— Zaphod being cool.