I have a resource server RS1 that is accessed via a REST API by an application App1. A user authorizes App1 to use its resources on RS1. In order to use RS1 services App1 has to acquire an access token from Keycloak. App1 is registered in Keycloak as a client with a client protocol openid-connect. App1 acquires the access token and is able to create resources for 90 days. When a resource is created, then that particular resource must be authorized again to complete its creation. This additional resource authorization should not change/replace an already existing access token and its permissions (the one that lasts 90 days).
One way I see it is that I could register App1 in Keycloak as a second client which acquires a short lived access token with a permission to that particular resource. In this case every application using RS1 will have two registered clients.
How do I go about it in Keycloak? Is Keycloak a right tool for that?
Related
I have two services: Service A and Service B
I have a central Identity Server that issues and validates tokens.
I need some of the resources of Service B to be accessed only by Service A.
How do I validate the audience, or how do I make sure that for ex.
the client credentials token of Service A is valid when calling
Service B, and tokens from other services are invalid.
Is it a bad practice or are there any issues in using authorization
code grant type for service to service authorization ?
When you issue a token for client credentials, then the subject of that token should be Service A. It will either be in the sub claim of a JWT (if you use JWTs for access tokens), or you will be able to get that information from an introspection endpoint (if you use opaque access tokens). Service B can use that information to reject any request with tokens where subject is not Service A.
Authorization code grant type assumes there is a resource owner (a user) and a browser available. It looks like in your case it will be impossible to implement authorization code flow, as you have two services talking directly to each other. Anyway client credentials should be enough for your needs.
This is more of an architecture question and not related to any specific technology. Let's say I have 2 rest microservices. A user has authority to service1, but not service2. However, service1 needs to access service2 for some side effect.
In my situation, service1 is actually public and you do not need a JWT to access it. Service2 requires an authenticated user.
One option I'm considering is that service2 allows calls from service1, but not from the user. That could be done with a generic JWT.
Does anyone have any suggestions? TIA!
In this case, service A should have permission to call service B, with a service user, and not with an end-user. If you are using oauth2.0, you should use client credentials. It is a grant type that is used to issue tokens to an authorized application using client id and client secret as credentials.
With this approach, service A will request a token to the OAuth server to access the endpoint of service B passing its client id and client secret and the OAuth server will give a token valid for service A to consume service B
We have a requirement where we need some service-to-service communication between two Quarkus microservices. The infrastructure is the following:
Authentication is done by another IDP application.
Service 1:
implements main domain logic
primarily used by the frontend
API is called with authenticated user (openID, JWT)
endpoints are secured with #RolesAllowed("XY")
Service 2:
should use secured API from Service 1
Service 1 API will not be called with authenticated user (execution by task scheduler and not frontend)
My main problem: if Service 2 would directly be called from the frontend, the solution would be to easily pass through the JWT token from Service 2 to Service 1. But since Service 2 is not called in the context of a user I don't have a JWT token which I can pass.
How should Service 2 authenticate with Service 1 in such a scenario?
Either you use the client credentials flow between Service 1 and Service 2, so that they can communicate securely without any user involvement. This means that they can communicate even when no user is present.
The alternative is to use Delegation Tokens, see these links
https://auth0.com/docs/tokens/delegation-tokens
https://www.scottbrady91.com/OAuth/Delegation-Patterns-for-OAuth-20
enter link description here
I am trying to wrap my head around the concept of bearer-only clients in Keycloak.
I understand the concept of public vs confidential and the concept of service accounts and the grant_type=client_credentials stuff. But with bearer-only, I'm stuck.
Googling only reveals fragments of discussions saying:
You cannot obtain a token from keycloak with a bearer-only client.
The docs are unclear as well. All they say is:
Bearer-only access type means that the application only allows bearer token requests.
Ok, if my app only allows bearer token requests, how do I obtain this token if I cannot get it from Keycloak using client id / client secret?
And if you can't obtain a token, what can you at all? Why do these clients exist? Can somebody please provide an example of using this type of client?
Bearer-only access type meaning
Bearer-only access type means that the application only allows bearer
token requests. If this is turned on, this application cannot
participate in browser logins.
So if you select your client as bearer-only then in that case keycloak adapter will not attempt to authenticate users, but only verify bearer tokens. That why keycloak documentation also mentioned bearer-only application will not allow the login from browser.
And if you can't obtain a token, what can you at all? Why do these clients exist?
Your client can't be set as bearer-only on Keycloak Server. You can
still use bearer-only on the adapter configuration though. Keycloak
doesn't allow "bearer only" clients (when setting up your client on
the server) to obtain tokens from the server. Try to change your
client to "confidential" on the server and set bearer-only on your
adapter configuration (keycloak.json).
So if you understand above statement then if you have two microservice which are talking to each other in the case, caller will be confidential and callee will be bearer-only
And Keycloak also mentioned
Bearer only client are web service that never initiate a login .It’s typically used for securing the back-end.
So if you want to use any adapter you can use bearer-only depend on the need
EDIT-
Lets go in more details ..Let see one example i have a web-app and one rest-api for web-app i am using React/Angular/JSF any front end technology and for back-end i am using Java based rest-api OR Nodejs.
Now for above requirement i have to secure both the products(web-app,rest-api) so what will be my work of action? How will I secure both the apps through Keycloak?
So here is details explanation
I have to create two client inside a realm in keycloak
Client A will be use by web-app
Client B will be used by rest-api
So now question will be why two client?
For web-app we want to force user to login via GUI then only generate the token
For rest-api we dont want GUI based api as these api consume by web-app but still secure the access to rest-api.
Now Go to Client A and make its Access Type public client so web-app will ask to login via keycloak GUI or your login page then generate the token
So same token which generated in above step used by rest-api and according to user role and other information data will fetch. So Access Type of Client B will be bearer-only so web-app generated token is passed to rest-api and it is then used to authorize the user .
Hope it will help. Someone want to add more he/she free to add.
Short answer: you can't obtain an access token using a bearer-only client, so authentication flow configuration is irrelevant, but keycloak may still need to know such a bearer only client to manage role / or audience
More details
bearer-only clients usefully represents back-end applications, like web service, called by front application and secured by the authorization server (= keycloak)
Backend / Web service application are not called directly by user, so they can't play in the Oauth2.0 user interactive flow. Setting "bearer-only" document this fact to keycloak server, allowing administrator to configure client without otherwise mandatory values (example redirect uri…) and allowing usefull error messages if someone trying to obtain a token for such a client
However, this doesn't mean you cannot configure specific roles for this client: so it need to appear in keycloak realm.
In addition bearer-only client need to verify the received access token, especially, if this (recommenden) adapter feature "verify-token-audience" is activated, bearer-only client need to verify that the access token has been issued for it: the bearer-only client must be in the audience attribute of the access token:
see https://www.keycloak.org/docs/latest/server_admin/index.html#_audience
for audience managing by keycloak, bearer-only clients needs to be registered in keycloak realm.
In my understanding, it is used when you have some internal service.
Let's say you have ServiceA and ServiceB. A user calls ServiceA which in hand calls ServiceB. ServiceB is never called by the user directly, only by other services. ServiceA will get a token using the user's credentials. And then will use this token to call ServiceB. ServiceB will never initiate a login. It will just use the token to verify permissions.
In this case, ServiceA will be confidential and ServiceB will be bearer-only clients.
An other idea why bearer only clients exist could be that client are misused for role containers sometimes, see the following discussion on the Keycloak User mailing list https://lists.jboss.org/pipermail/keycloak-user/2016-April/005731.html
E. g. the default client "realm-management" is a bearer only client, that contains roles to manage things in a realm. There is no need to invoke a login on a client like this, so public and confidential doesn't make any sense.
I understand that keycloak has built-in clients and we add the users later on.
But in general, what is the difference between a client and a user in Keycloak?
According to the Keycloak documentation
User - Users are entities that are able to log into your system
Client - Clients are entities that can request Keycloak to authenticate a user. Most
often, clients are applications and services that want to use Keycloak to secure
themselves and provide a single sign-on solution. Clients can also be entities that
just want to request identity information or an access token so that they can
securely invoke other services on the network that are secured by Keycloak
In short words, not only for keycloak but for OAuth and OpenId Connect too, a client represents a resource which some users can access. The built-in clients for keycloak represent some resources for keycloak itself.
Clients and users are two completely different constructs in keycloak.
In plain English, client is an application. Example for an application could be a e.g. yelp.com or any mobile application. Client can be a simple REST API. Keycloak's built in clients are for keycloak internal use, But any user-defined application has to be registered as a client in keycloak.
Users are the one which authenticate via keycloak to gain access to these applications/clients. Users are stored in keycloak DB or any externally hosted LDAP but synced with keycloak.