I have a spring boot (backend) & angular (frontend) app that I'd like to secure with keycloak (for the authentication).
I have a very basic deployment, in which the executable jar created by spring also serves the client code (from angular).
I have seen several tutorials where the front and back are separated, and the front uses the code flow + pkce to delegate its authentication to keycloak, while the back is stateless and checks for presence of a jwt token certified by the keycloak instance.
However since I have a backend server, I'd like to avoid using a public client and instead rely on the back-channel token exchange on the server side. So the front should not have any knowledge of the keycloak instance.
Is that possible / is it a best practice ? Is there a front library that helps me to achieve that ? I've come across the library keycloak-angular, but it seems to be directed towards the first case, where the SPA connects directly to Keycloak instead of using a backend server.
In such a case you don't need a frontend library. In your frontend you should just handle user session (have a session cookie) and send the cookie every time to your backend. Then the backend server should use any oauth client to communicate with your keycloak server, and once it gets the tokens it can save them in a db together with a handle to your session.
Here's how this flow might look like:
request client -> backend server -> reply with a 302 to the keycloak authorization endpoint. Registered redirect_uri should be a uri exposed by the backend server
user performs authentication / consent, etc.
Keycloak redirects to redirect_uri with code
Backend receives code (as it listens on the redirect uri address), and exchanges it with Keycloak.
Backend receives access token and saves it in a DB together with session ID.
When clients makes another request to backend with their session, backend picks an access token from the DB and can call an API.
Related
I have used Microservice Architecture in an Enterprise Application. There are more microservices in my architecture using Spring Boot. I have made a my own Microservice as Authorization service using Keycloak. Here I'm doing Authentication in every Microservice calling to Authorization Service & get JWT Token. on every endpoint, call to Authorization service to validate JWT Token & give permission. when this Application is used by Millions of Users, couldn't Authorization Server be Busy. How to Handle Load here. I think, making more instances of Authorization Service and Balance Load is not Good Practise to the Authorization Server.
give me a Solution good for industrial Application
New JWTs should not be fetched for each request: a given OAuth2 client should use the same access-token until it expires.
JWT are signed and can be validated by clients and resource-servers without the help of the authorization-server (only a single call at startup to fetch signing public key is required).
So no, authorization-server should not be specially stressed.
My apologies for my bad english.
I have the tool Apereo CAS using as login SSO. When i'm using with application statefuls this works very well. But i wanna call a API REST (stateless) for specific scenario and validate the logged user (and using your informations on the service). My backend API is developed with Spring Boot. Someone needed a similar situation?
Ps: This API will acess by frontend and services without frontend therefore I'll not be able to use cookies.
Sequence Diagram to exemplify my idea:
enter image description here
Thank's.
Your front-end application needs to ask the CAS server for proxy authentication.
One of the more common use cases of proxy authentication is the ability to obtain a ticket for a back-end [REST-based] service that is also protected by CAS. The scenario usually is:
User is faced with application A which is protected by CAS.
Application A on the backend needs to contact a service S to produce data.
Service S itself is protected by CAS itself.
Because frontend contacts service in the back-end via a server-to-service method where no browser is involved, the backend would not be able to recognize that an SSO session already exists. In these cases, front-end needs to exercise proxying in order to obtain a proxy ticket for the backend. The proxy ticket is passed to the relevant endpoint of the backend so it can retrieve and validate it via CAS and finally produce a response.
The trace route may look like this:
Browser navigates to front-end.
Front-end redirects to CAS.
CAS authenticates and redirects back to front-end with an ST.
Front-end attempts to validate the ST, and asks for a PGT.
CAS confirms ST validation, and issues a proxy-granting ticket PGT.
Front-end asks CAS to produce a PT for back-end API, supplying the PGT in its request.
CAS produces a PT for backend API.
Front-end contacts the service S endpoint, passing along PT in the request.
backend API attempts to validate the PT via CAS.
CAS validates the PT and produces a successful response.
Backend API receives the response, and produces data for front-end.
A receives and displays the data in the browser.
See this for details.
We are using keycloak-adapter with Jetty for authentication and authorization using Keycloak.
As per Keycloak doc for OIDC Auth flow:
Another important aspect of this flow is the concept of a public vs. a confidential client. Confidential clients are required to
provide a client secret when they exchange the temporary codes for
tokens. Public clients are not required to provide this client secret.
Public clients are perfectly fine so long as HTTPS is strictly
enforced and you are very strict about what redirect URIs are
registered for the client.
HTML5/JavaScript clients always have to be public clients because
there is no way to transmit the client secret to them in a secure
manner.
We have webapps which connect to Jetty and use auth. So, we have created a public client and it works awesome for webapp/REST authentication.
The problem is as soon as we enable authorization, client type gets converted to Confidential from Public and it does not allow the reset it as Public. Now, we are in soup. We cannot have public clients due to authorization and we cannot connect webapps to confidential client.
This seems to be contradictory to us. Any idea why client needs to be confidential for authorization? Any help on this how can we overcome this issue?
Thanks.
As far as I understood, you have your frontend and backend applications separated. If your frontend is a static web-app and not being served by the same backend application (server), and your backend is a simple REST API - then you would have two Keycloak clients configured:
public client for the frontend app. It would be responsible for acquiring JWT tokens.
bearer-only client, which would be attached to your backend application.
To enable authorization you would create roles (either realm or client scoped, start on the realm level as it's easier to comprehend). Every user would then be assigned a role/s in the Keycloak admin UI. Based on this you should configure your keycloak adapter configuration (on the backend).
All things considered, in order to talk to your REST API, you would attach a JWT token to each HTTP request in the Authorization header. Depending on your frontend framework, you can use either of these:
Keycloak js adapter
Other bindings (angular, react)
P.S. For debugging I have just written a CLI tool called brauzie
that would help you fetch and analyse your JWT tokens (scopes, roles, etc.). It could be used for both public and confidential clients. You
could as well use Postman and https://jwt.io
HTH :)
I think you are referring to the "Authorization Enabled" switch in the admin console of Keycloak, when creating a client. If you go over the question mark next to the label, you'll see the hint "Enable/Disable fine grained authorization support for a client.
Create client in Keycloak admin console (v 6.0.1)
This is meant for when you create a client for a backend application that serves as a resource server. In that case, the client will be confidential.
If you want to create a client for a frontend app, to authenticate a user and obtain an JWT, then you don't need this.
See also: https://www.keycloak.org/docs/latest/authorization_services/index.html
After much deliberation, we found that authorisation is not required to be enabled on public client really when you connect to it. When any request come to public client, it only does the authentication part. Authorization part is done when actual request lands on the resource server (in our case, Jetty) using the confidential client (as Jetty has knowledge of confidential client configured in it).
I have a Java Spring driven REST API server connecting with PostgreSQL database and a Spring Web Server in Java that is serving content from the REST API to the client using JavaScript (now browsers, but in the future also mobile apps).
I've read a number of articles and topics how one can secure a REST API, but I haven't been able to make a final decision yet. I don't want to have Basic Authorization, because it doesn't make sense as I would need to store credentials in JavaScript that can be easily accessed and read by anyone entering the webpage and developer console. I'd like not to show any credentials to the end user so I can't keep them on the client's side.
I've read a lot about JWT and almost decided to implement it, but I've heard it has some drawbacks and haven't been so sure since then if it's the option I would like to choose. I know there is also oAuth 1.0 or oAuth 2.0 but I don't know if I want to have something this complicated. I would also like to store hashed user credentials in my own database in order not to be depended to any other credential providers like social media or Google.
Now I'm making another layer on my web server as a proxy hoping that it will allow me to authenticate user on this proxy level using Spring Security and having some kind or cookies or something to authenticate, but I'm not so sure if its doable this way and it increases the respond time, adds complexity and needs me to write controller methods for these endpoints. My architecture now is of the following:
Client (browser) -> Webserver -> REST API server -> db
I've also denied all external connections and allowed only localhost access to REST API on tomcat level so that I'd have to implement the security level only on the web server allowing free information transit between the webserver and REST API as it is not reachable anyway.
Web server and REST API are on the same server running as Tomcat instances.
I'm also not so sure if this kind of architecture will allow me to authenticate mobile app clients through the web server.
I would be very grateful for any piece of advice you would have for me in this matter. I'm not so experienced in security, so I'm a bit lost what I should do. Does this kind of architecture any sense or should I simply ask REST API directly from any type of clients, be it a webpage or a mobile app from different IPs and secure Rest API only? And if I want to secure some subpages of my webpage or parts of mobile app should that be an completely other layer?
Thank you for your help.
You have already gone through OAuth, JWT tokens etc. If you don't want to use them,then you can create your own token based authentication system.(say 'TokenHandler').
How this TokenHandler will work ?
TokenHandler will be like a gateway server i.e your every REST API request will route through this server application. So you will address your confusion of mobile and web application call with a authToken in header. Main responsibility of this server applciation is to accept the token and validate against the database where all token details are maintain. This DB will have information regarding timestamp when token was last used to validate, to decide your validation rule .
How Token will get generated ?
Token can be any random 64 digit alphanumeric string and will be generated and updated in DB during every single login activity. Login webservice returns this token in response body.
What can be rules for validation ?
It can be depending on your business logic. I preferred to keep active session window of 15 mins. Means if you access the webservice you will get active window of 15 more minutes. If you didn't access any service for 15 consecutive minutes then from 16th Minute you will need to login again to access further calls. This part can change according to requirements.
How client side will handle this ?
Client side will store this token and pass this token with every request call. Token Handler will validate and redirects it's request to the application server . So your one token handler can be used to server authentication of multiple applcation servers. This you can achieve by application end point identifer.
I will like to discuss further if you have any questions or suggestions .
Use API Gateway Architecture Pattern for your use case -
http://microservices.io/patterns/apigateway.html .
The API Gateway (The webserver in your question) can act as single entry point for all desktop/mobile clients. You can use either session cookies or jwts to authenticate clients at gateway.
With respect to authentication between gateway and micro services, and between micro services, i would suggest mutual ssl - https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication. If you are using spring boot, this might help - http://www.opencodez.com/java/implement-2-way-authentication-using-ssl.htm
The problem with IP white-listing approach is that - it's not well suitable for cloud architecture as the IPs might change with every server reboot. Even if you are using dedicated IPs, you should be careful to secure the communication with SSL/TLS, else attackers can easily sniff your traffic.
I have a Spring-MVC (Spring 4) based server that provides a REST service to an outside client (IE, I do not have a view hosted on my server). A requirement has been added to add a login service to the REST which authenticates against a backend server.
My question is: How do I add a login request to the REST server in such a way that every request that goes to the server first goes through a check to see if the user has authenticated and if there is an active session, and returns an error if this is not the case? Preferably, this should be transparent to other requests, and should not require a code change at the other #RestController based classes.
Thanks