7:36 a.m.
On Tue, Nov 5, 2019 at 9:08 AM Pete Chown <pete_keycloak(a)chown.org.uk>
wrote:
Hi Pedro,
Thank you for taking the time to reply, and for the information.
On 31/10/2019 15:14, Pedro Igor Silva wrote:
> Authorization services are targeted for resource servers protecting
> their resources. That is one of the reasons for requiring the client to
> be confidential. They also need to perform operations that only a
> confidential client can do given that client authentication is required.
Perhaps I'm misunderstanding how this is supposed to work, but isn't the
difference between a public and a confidential client quite small? With
the public client, the end user obtains a token proving their right to
access a resource. With the confidential client, the end user sends a
code, and the confidential client asks the authentication server whether
the user is authorised to access the resource.
The public and confidential clients usually have different roles. The first
is usually acting on behalf of the user (as most SPAs do) in order to
access protected resources served by a specific service. The latter is
usually the actual service (a.k.a: resource server) that serves protected
resources.
Yeah, the public client obtains a token and access resources on behalf of
the user. But the confidential one is usually consuming that token to check
whether or not access should be granted. It is not really acting on the
user's behalf.
Is there a particular reason to favour the second option when
authorisation is required?
It does not make sense to protect resources for public clients (e.g.:
frontends) as they actually consume data from another source where the
protected resources actually reside. You can, however, build your frontends
in a manner that the token you get from the server is used to
hide/show/enable/disable things in the UI. In this case, the frontend and
backend are coupled so that they are both aware of the protected resources.
What are the "operations that only a confidential client can do"? Again
I may be misunderstanding, but I thought the authorisation service just
modified the issued tokens to reflect the user's access rights.
Obtain token with permissions on its own behalf is an example. Another is
to manage resources through the Protection API. I and would also mention
one last that is related to being able to access the token introspection
endpoint.
> However, you are still able to use authorization services in a public
> client. I mean, obtain tokens with permissions from the token endpoint.
Excellent! How do I do this? The authorisation services seem to be
disabled in the admin GUI when the client is not confidential.
Maybe we should first understand better your use case and what you are
trying to achieve. As a reference, I would suggest you look two quickstarts:
*
https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-ph...
*
https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-sp...
The first one is a SPA + Backend (protected with authz).
The second one is a server-side web-app protected with authz.
> As per confidential being equivalent to the public, conceptually they
> are not. But in practice, if you expose or you don't protect your client
> secrets you will be indeed compromised.
This makes sense but I thought it was worth asking! :)
Thanks again,
Pete
> On Mon, Oct 28, 2019 at 12:46 PM Pete Chown <pete_keycloak(a)chown.org.uk
> <mailto:pete_keycloak@chown.org.uk>> wrote:
>
> Hello,
>
> I have a public client and I can issue tokens for it. I would like
to
> be able to use Keycloak for access control as well, so for example I
> might give a user the "admin" role and that would cause additional
> scopes to be added to their tokens.
>
> Unfortunately it looks as though the authorisation aspect of
> Keycloak is
> only available to confidential clients. First of all, is that
correct?
>
> If my understanding is correct, is there some specific security issue
> that arises if authorisation is applied to public clients? I can't
> think of one, but perhaps I just haven't thought hard enough. :)
>
> Suppose I have a confidential client, but I don't take any steps to
> keep
> the "secret" secure. Is it then equivalent to a public client? In
> other words could I work around this issue by making my client
> nominally
> confidential, but not taking steps to conceal the secret? (There are
> actually no steps I could take, because my client is just Javascript
> running in a web page.)
>
> Thank you for any help you can give, and many thanks to the
developers
> for this excellent software.
>
> Pete
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user