I was checking OWASP cheatsheet on how to improve security in a frontend client using a JWT to interact with the backend.
The approach they suggest is to basically add a claim in the JWT which contains an encoded "fingerprint" which is also sent via a hardened cookie.
The fingerprint is verified in the backend by checking that the claim and the cookie contains the same fingerprint. Here the OWASP Cheatsheet entry
When using Keycloak, is it possible to use such approach? Is Keycloak JavaScript adapter "secure" enough?
Related
I'm building a microservice based REST API and a native SPA Web Frontend for an application.
The API should be protected using OAuth2.0 to allow for other clients in the future. It should use the Authorization Code Flow ideally with Proof Key for Code Exchange (PKCE)
As I understand it I need to run my own OAuth Auth Server that's managing the API Clients and generating access tokens, etc.
Also I need my own Authentication/IAM service with it's own fronted for user login and client authorization granting. This service is the place the users login credentials are ultimately checked against a backend. That last part should be flexible and the backend might be an LDAP server in some private cloud deployment.
These components (Auth Server and IAM servicve) are outside of the OAuth scope but appear, correct me if I'm wrong, to be required if I'm running my own API for my own users.
However creating these services myself appears to be more work than I appreciate besides the obvious security risks involved.
I read about auth0 and okta but I'm not sure if they are suited for my use case with the application potentially deployed in private cloud.
I also thought about running Hydra (OAuth Server) and Kratos (IAM) by ory but I'm not sure if this is adding too many dependencys to my project.
Isn't there an easy way to secure an API with OAuth that deals with the Auth Server and the IAM that's good for small projects?!
We are currently evaluating the possibilities of keycloak since we need to replace a custom SSO solution. This requires us to connect to external IDPs which we already connected to.
Currently I am investigating an OpenID-Connect Provider which is authenticating the clients via POST using client_id and client_secret as parameters. Additionally, its API is secured with a basic authentication via the Authorization header. Whilst the first part is no problem, I have not found a solution to overcome the additional basic authentication with the available default configurations (using a user-defined OpenID Connect V1.0 provider). Vice versa, I can overcome the basic authentication, but then will miss the client_id and client_secret parameters which results in an error of the IDP not returning an access token.
Is there a way to resolve this issue? If not via default options, is there an option to add custom IDPs which can be configured in the backend? I saw the SPIs in the developer documentation (https://www.keycloak.org/docs/latest/server_development/#_providers) but I am not sure if one of those suits our needs.
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.
What are good arguments in favor to use or not to use Keycloak behind Api gateway (Kong)?
There is a tradeoff to putting it behind the proxy: you will not be able to easily protect all of your services by applying the OIDC plugin on the global level. Instead, you will need to individually configure every service with its own OIDC plugin. This is because you will need at least one service that is not protected by the OIDC plugin so that user-agents can authenticate through that service. Unless you're planning to implement some other form of security on that service or need some other services that Kong can easily implement as requests pass through it, I don't see the point of putting Keycloak behind the proxy. That's not to say there aren't good reasons to do it, I'm just not aware of them.
I've set Keycloak up outside of the proxy, and have had good results. Here's what it looks like:
I'm writing a blog post about this set up now which I will release next week. I will try to remember to update my answer here when it is complete.
Edit
Links to blog:
Part 1,
Part 2
It is not good practice, in fact I would suggest to put it outside, in the DMZ. In this way that IDP can be leveraged by all APIs that you want to publish and authenticate using the API gateway. This is an example of applying such authentication flow with Keycloak: https://www.slideshare.net/YuichiNakamura10/implementing-security-requirements-for-banking-api-system-using-open-source-software-oss
Your concern might be then: how do I protect such a critical resource like an IDP authenticating all my services?
Reasonable concern which you can address by:
ensuring autoscaling of the IDP based on authentication request
configuring all the needed threat mitigation options on Keycloak (https://www.keycloak.org/docs/latest/server_admin/#password-guess-brute-force-attacks)
add a WAF in front of the IDP with feature such as DDOS prevention and Intelligent Threat Mitigation based on traffic patterns
IP or Domain whitelisting, if you know where all your customers are connecting from
restrict port exposure for the IDP
Kong is an API gateway that'll be in the "hot path" - in the request and response cycle of every API request. Kong is good at efficiently proxying lots of requests at very low latency.
Keycloak and other IAM offerings can integrate with Kong - but they aren't placed in the hot path. Keycloak is good at managing users and permissions and providing this information to systems like Kong, when requested.
Perhaps these links will be helpful https://github.com/ncarlier/kong-integration-samples and https://ncarlier.gitbooks.io/oss-api-management/content/howto-kong_with_keycloak.html
Is not a good practice, a good Enterprise API Gateway has the obligation to meet (or give you the access to customize) all the advanced authentication and authorization standards available in KEYCLOAK.
But in some circumstances, If you already have a API Gateway with a lot API´s configured (with transformation rules, route rules) and this Gateway can´t provide advanced features for authentication and authorization (ex. 2 factor authentication or Oauth2 authorization code/openId / SAML) and you need more security ASAP, go ahead while looking for a gateway that best meets your needs
We are implementing RESTful service and the entire backend application using Vert.x. These API's are consumed by a hybrid mobile app (developed using Ionic / angularjs). We are using Keycloak for user management and also authentication and authorization on the app.
My question is, how can I use Keycloak to also protect (authenticate and authorize for the same set of users) my RESTful service access which is implemented using Vert.x. Any example implementation would be very useful.
We wrote a custom Vert.x auth provider using the Keycloak core library to solve this exact problem (the Vert.x JWT library doesn't work with the Keycloak JWT tokens - arguably we should have improved the Vert.x library instead). I'll see if I can get permission to open source the library.
So, if i understand correctly, you need one authentication entry point for user in mobile app and in REST service. If i am right, you can use JWT. When user will authenticate with Keycloak he will receive jwt with roles and user information. This token you can put into request for REST service and your Service will know who is the user and what roles he have. Please see https://jwt.io/