Recommended setup for REST-like web service
Jesse Bickel
David Cook
I’m sure someone else will have a better answer for machine to machine interactions but I’ll share what I know generally.
When securing a web app with a Keycloak OIDC provider, you set up a Keycloak realm and a Keycloak client using the Authorization Grant. You configure your web app’s OIDC client using the Keycloak client credentials. When a human user visits your web app using a web browser, your web app redirects the human user’s browser to the Keycloak realm. The human user fills in their username and password, Keycloak verifies it, and then redirects the web browser back to your web app’s OIDC client which then retrieves an access token and an ID token.
Now for your case there is no human and no web browser so you can’t use the Authorization Grant, but I think you might be able to use Direct Access Grants. In that case, your web service will have the OIDC client (including the client id and client secret), and it’ll need to collect and on-send the username and user password from the machine using the web service to the OIDC provider. How you collect that user name and user password is up to you.
If you’re just using Keycloak for authentication, then that should be it. If you’re using it for authorization too, then you’ll need to get more information from someone else.
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
--
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 on the web visit https://groups.google.com/d/msgid/keycloak-user/cfb0db28-d90b-4d85-a704-a032aa01db11n%40googlegroups.com.
Jesse Bickel
When securing a web app with a Keycloak OIDC provider, you set up a Keycloak realm and a Keycloak client using the Authorization Grant. You configure your web app’s OIDC client using the Keycloak client credentials. When a human user visits your web app using a web browser, your web app redirects the human user’s browser to the Keycloak realm. The human user fills in their username and password, Keycloak verifies it, and then redirects the web browser back to your web app’s OIDC client which then retrieves an access token and an ID token.
Now for your case there is no human and no web browser so you can’t use the Authorization Grant, but I think you might be able to use Direct Access Grants. In that case, your web service will have the OIDC client (including the client id and client secret), and it’ll need to collect and on-send the username and user password from the machine using the web service to the OIDC provider. How you collect that user name and user password is up to you.
If you’re just using Keycloak for authentication, then that should be it. If you’re using it for authorization too, then you’ll need to get more information from someone else.
C R
The Direct Access grant is almost never what you want or need, and if
a was a user, I would not use your service because of fear of you
stealing my credentials. Like David writes, for regular users you just
need the "standard" flow, known as the authorization code grant.
For machine-to-machine connections, there are different ways to
implement it. The simplest is just **locally** validate a JWT that the
remote machine retrieves itself from somewhere. Just make sure the
signature is valid and the token has not expired. For long lived
tokens, if you want, you can contact the token endpoint of Keycloak.
If there is no user context, the remote service can receive a service
account token which it can receive after authenticating with its own
client id and secret. You can restrict which token are valid by
requiring specific scopes or roles.
Regards,
CR
Le mer. 16 nov. 2022 à 23:49, Jesse Bickel
<jbi...@opentechstrategies.com> a écrit :
> 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.
Jesse Bickel
The Direct Access grant is almost never what you want or need, and if
a was a user, I would not use your service because of fear of you
stealing my credentials. Like David writes, for regular users you just
need the "standard" flow, known as the authorization code grant.
For machine-to-machine connections, there are different ways to
implement it.
The simplest is just **locally** validate a JWT that the
remote machine retrieves itself from somewhere.
Just make sure the
signature is valid and the token has not expired. For long lived
tokens, if you want, you can contact the token endpoint of Keycloak.
If there is no user context, the remote service can receive a service
account token which it can receive after authenticating with its own
client id and secret. You can restrict which token are valid by
requiring specific scopes or roles.
David Cook
You’ve got way too many questions for me to try to answer this line by line, but I had a thought…
Originally, you said “I would like to protect some web API endpoints with keycloak. These will be accessed by machine users across the internet.”
What machine users are these? Is this an IoT scenario? And you’re hoping to have each device be a “User”?
If so, you might want the “OAuth 2.0 Device Authorization Grant”. I don’t really know anything about it, but I just learned about Keycloak’s support of it after a bit of Googling. Check this link out: https://keycloak.discourse.group/t/oauth-2-0-device-authorization-grant/8890/5
--
I’d encourage you to keep exploring Keycloak, as I think your idea that “authentication and authorization could be streamlined without much customization” is a worthwhile one. I mostly support existing apps with their own custom AuthN/AuthZ, but if I were to write something new from scratch, I’d be trying to use IDAM software like Keycloak to take care of AuthN/AuthZ.
As I said before, I haven’t used Keycloak’s more advanced AuthZ capabilities, so I can’t help there, but I’d encourage you to read and experiment. (That said, I have created custom claim mappers to surface Groups and User Attributes, so that downstream apps can make authorization decisions based off Keycloak data, but that’s still custom AuthZ based on custom logic – it’s not using Keycloak’s fine-grained authorization policies.)
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: keyclo...@googlegroups.com <keyclo...@googlegroups.com> On Behalf Of Jesse Bickel
Sent: Friday, 18 November 2022 4:49 AM
To: Keycloak User <keyclo...@googlegroups.com>
--
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 on the web visit https://groups.google.com/d/msgid/keycloak-user/01f11570-5a86-4c38-89e7-5609badc1a2fn%40googlegroups.com.
Jesse Bickel
Originally, you said “I would like to protect some web API endpoints with keycloak. These will be accessed by machine users across the internet.”
What machine users are these? Is this an IoT scenario? And you’re hoping to have each device be a “User”?
I’d encourage you to keep exploring Keycloak, as I think your idea that “authentication and authorization could be streamlined without much customization” is a worthwhile one. I mostly support existing apps with their own custom AuthN/AuthZ, but if I were to write something new from scratch, I’d be trying to use IDAM software like Keycloak to take care of AuthN/AuthZ.
C R
<jbi...@opentechstrategies.com> a écrit :
may need to unpack the claims to verify a scope or role is there, but
it's trivial and it should be documented by the library.
>> For machine-to-machine connections, there are different ways to
>> implement it.
>
>
> Darn. I was hoping there is a streamlined way, a de facto standard way that is not too cumbersome to machine Users (either by a simple nature or by availability of libraries) and decently secures the service/RP/Client against unauthenticated/unauthorized use.
>>
>> The simplest is just **locally** validate a JWT that the
>> remote machine retrieves itself from somewhere.
>
>
> Does "locally" mean the service/RP/Client? The remote machine is the machine User? The User retrieves this JWT from the OP? Using which flow? Implicit flow?
My 2c.
- ignore all the other flows besides the authorization code, except if
you **really** know what you're doing.
- If there is a user context (==user logs in interactively), use the
authorization code.
- If there is no user context (== a background job in de client
application, not one run by the user), use the authorization code for
the service account of the application.
C.
Jesse Bickel
Standard oidc/oauth2 libraries for your language will do the job. You
may need to unpack the claims to verify a scope or role is there, but
it's trivial and it should be documented by the library.
>> For machine-to-machine connections, there are different ways to
>> implement it.
>
>
> Darn. I was hoping there is a streamlined way, a de facto standard way that is not too cumbersome to machine Users (either by a simple nature or by availability of libraries) and decently secures the service/RP/Client against unauthenticated/unauthorized use.
You can use the same code as for users. Zero extra coding. See below,
>>
>> The simplest is just **locally** validate a JWT that the
>> remote machine retrieves itself from somewhere.
>
>
> Does "locally" mean the service/RP/Client? The remote machine is the machine User? The User retrieves this JWT from the OP? Using which flow? Implicit flow?
[...]
My 2c.
- ignore all the other flows besides the authorization code, except if
you **really** know what you're doing.
- If there is a user context (==user logs in interactively), use the
authorization code.
- If there is no user context (== a background job in de client
application, not one run by the user), use the authorization code for
the service account of the application.
C R
David already mentioned the Device Authorization Grant. It works like
how to link a Chromecast in case you've seen it before. Make sure the
token is kept long enough in the client or that it can be refreshed.
C.
Le lun. 21 nov. 2022 à 16:50, Jesse Bickel
<jbi...@opentechstrategies.com> a écrit :
>
> 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.
Jesse Bickel
Is it a command line application we're talking about? In that case,
David already mentioned the Device Authorization Grant. It works like
how to link a Chromecast in case you've seen it before. Make sure the
token is kept long enough in the client or that it can be refreshed.