My rest api on spring boot application is secured with spring security Oauth2 client credentials with memory token.
How can I horizontal scale my application so access token will be valid in any scaled instances ?
I am guessing that you are running an Authorization Server that is embedded in your Spring application. If you want to scale horizontally you need to separate the two concerns. There are two ways to do this.
Run multiple REST / API servers and a single separate authorization server. The JWT granted by your single authorization server would be valid across all your REST / API servers as long as you configure your verifier correctly.
If you can for your project, use a third party authorization service like Auth0 or Okta to grant JWTs. The JWTs granted by these services would be valid and verifiable across all of your REST / API servers. These services will make your life easier since the provide HA and scalable Authorization server implementations. They are also more secure than trying to run your own authorization server.
Related
I have a spring based application which does authentication and authorization(oauth2 based) for a client app.I want to now use keycloak to manage my authorizations, but i want to keep my spring code. Basically i want to use my existing auth code as an external identity provider in keycloak.
I am thinking of adding changes in client app such that it receives token from my existing oauth code(which does the authentication) and then exchange this token with keycloak(for session and authorization management). How can i do this? What configurations need to be done in keycloak?
I read about token exchange in keycloak here, but i am not clear about the kind of token i need to send from my existing auth code.
https://www.keycloak.org/docs/latest/securing_apps/
Here is how OAuth2 roles are usually spread:
Keycloak is authorization-server
Spring service is resource-server
front-end is client
user is resource-owner
I have a doubt of you wanting your Spring service to be "authorization-server" as well (serve user identity). If so, I think you should not.
Keycloak (or any other OpenID provider) should be the only authorization-server. Both Spring and client(s) should be configured to use it as so.
To write it differently, Keycloak is responsible for users login and emitting tokens with user ID (subject) and rights (roles or whatever). Other tiers in the architecture (clients & resource servers) get user info from the token and apply relevant security checks (spring security annotations, Angular guards, etc.).
I published a mono-repo for a meetup with minimal sample involving a Spring resource-server and Angular (with Ionic) client talking to a Keycloak OpenID authorization-server. You might find some inspiration browsing it.
I have two spring boot application. One is Rest and the other one is Spring boot web MVC app which consumes the Rest. The Rest has spring security configured and I want to login/logout from the client app. The client app has nothing but view and controllers to interact with the rest api.
I am using rest template to interact with the api now.
If the client app is not secured so any other anonymous app may do the same, and this is not security, it's a sieve ...
If you want to create a custom authorization/authentication, you can create own protocol and use tokens/JWT (possibly, OpenID or other global technology) and exchange information between applications.
But there is technology to do it all centrally and reliably - OAuth2, and Spring has it 'from the box' - authorization server, resource server, client. The most advantage - multiple applications (clients), one authorization - you create one user and can authenticate it on any client with the same credentials. You can customize it with JWT, and use any data in the access token and as a consequence get any information about principle/authorization.
I have gone through many posts and articles but didn't find a straightforward solution for the case below which I have to implement.
Platform: Spring Boot 2.x.x (Spring Security 5.x.x) with embed Tomcat
Solution: REST service that consume many client apps and many end users.
I have to implement a REST end point /api/search which accessible for many client application. As an example, web application APP-X (Angular), web application APP-Y(Jquery/Bootstrap) and mobile application APP-Z (IOS). All three clients are separate entities (both technical perspective and business perspective).
So I have to authenticate above application using onetime token. Therefore I planned to go for Spring OAuth2 by enabling #EnableAuthorizationServer and #EnableResourceServer. For each app client I’ll generate a token and they can use it when they connect with my REST service. Is this approach correct?
Apart from the app clients system has capability to register and login functionality for end users. Also my end point (/api/search) can access both anonymous users and users who registered under ROLE_REGUSER role. And through the security context, I need to access the user details as usual user authentication.
This is the place I got stuck. How can I handle the following points together using Spring Security 5.x.x (Spring Boot 2.x.x).
I. Both client apps and end users authentications.
II. Allow access for anonymous users and registered users for same end point.
I have attached small diagram to elaborate the above scenario.
Thanks
I found a solution when I upgraded my spring security version to 5.2. In version 5.2, they have depreciated #EnableAuthorizationServer and #EnableResourceServer. So I had to move with an external authorization provider who supports auth2. I chose AWS Cognito, and fulfill the above requirement, using the user pool option.
In AWS Cognito
I created a user pool.
Then created two app clients in the same user pool.
One app client configured as support to the client credentials flow.
The second app client configured as support to the user authentication flow.
In client applications
Retrieve access token directly from AWS Cognito using client credentials and used to secure all API calls.
If a user login at any stage, retrieve access token directly from AWS Cognito using the authorization code and replace any existing access token.
The advantage is, the resources server can validate any access token that generated related to the same user pool.
In resources server (backend API/Spring Boot)
Validate access token.
I have a spring cloud oauth #EnableAuthorizationServer that uses a jpa backend to store the accounts. I also have a couple of different clients, a website, an intranet and a ionic mobile app.
all the clients have separate client credentials inline in the oauth config block.
i have then tried to use the spring cloud sso to not have to login again.
my problem is that I want to remove the authorize step since all my clients are known to me and i simply want the user to be logged in across all my apps.
is this possible with spring cloud sso?
The authorization happens on the authorization server (so nothing to do with Spring Cloud). A UserApprovalHandler would do what you need, but the default one should work if you just set autoapprove=true (or a pattern matching te scopes you want to auto approve) in the client details. (Assuming your auth server is Spring OAuth.)
I have updated the jhipster generator from version 1 to version 2. In the previous version we had to choices of authentication when generating a new project. We had the choice between Cookie authentication and Token authentication (with OAuth). This was very clear for me. But in version 2.1.1, we have now three choices :
1 > HTTP Session Authentication (stateful, default Spring Security mechanism)
2 > OAuth2 Authentication (stateless, with an OAuth2 server implementation)
3 > Token-based authentication (stateless, with a token)
I want to used the authentication both for web and mobile app (ionic-framework), which one to one between 2 and 3 ? Is this choice make my app scalable using clusters ?
Thanks
you will the basic info about jhipster authentication type here
http://jhipster.github.io/security/
from my personal experience in ionic-framework working with REST api of jhipster, I can say that don't use HTTP Session Authentication for mobile app (ionic-framework) because mobile apps don not play along with cookies in general which HTTP Session Authentication depends upon.
Both Oauth2 and JWT work fine with ionic hybrid app
HTTP Session Authentication
This is the "classical" Spring Security authentication mechanism, but we have improved it quite significantly. It uses the HTTP Session, so it is a stateful mechanism: if you plan to scale your application on multiple servers, you need to have a load balancer with sticky sessions so that each user stays on the same server.
OAuth2 Authentication
OAuth2 is a stateless security mechanism, so you might prefer it if you want to scale your application across several machines. Spring Security provides an OAuth2 implementation, which we have configured for you.
The biggest issue with OAuth2 is that requires to have several database tables in order to store its security tokens. If you are using an SQL database, we provide the necessary Liquibase changlog so that those tables are automatically created for you.
As Spring Security only supports OAuth2 with SQL databases, we have also implemented our own MongoDB version. We generate for you all the OAuth2 implementation for MongoDB, as well as the necessary MongoDB configuration.
This solution uses a secret key, which should be configured in your application.yml file, as the "authentication.oauth.secret" property.
JWT authentication
JSON Web Token (JWT) authentication, like OAuth2, is a stateless security mechanism, so it's another good option if you want to scale on several different servers.
This authentication mechanism doesn't exist by default with Spring Security, it's a JHipster-specific integration of the Java JWT project. It is easier to use and implement than OAuth2, as it does not require a persistence mechanism, so it works on all SQL and NoSQL options.
This solution uses a secure token that holds the user's login name and authorities. As the token is signed, it cannot be altered by a user.
The secret key should be configured in the application.yml file, as the jhipster.security.authentication.jwt.secret property.