I have 2 applications:
Spring Application 1 is client and resource server.
Spring Application 2 is authorization server.
User will be able to login in Application 1 and access its resources.
And I want to implement the following flow:
User enter his credentials in login form -> Application 1 will get token from Application 2 using user credentials and its clientId with password grant type -> Access resources of Application 1 with token.
The question is if Spring Security 5 supports password grant type for client? I found all rest grant types, but not password in Spring Security 5 implementation.
Spring Security 5.1.x doesn't support it, see Spring Security Reference:
6.6 OAuth 2.0 Client
The OAuth 2.0 Client features provide support for the Client role as defined in the OAuth 2.0 Authorization Framework.
The following main features are available:
Authorization Code Grant
Client Credentials Grant
WebClient extension for Servlet Environments (for making protected resource requests)
HttpSecurity.oauth2Client() provides a number of configuration options for customizing OAuth 2.0 Client.
However, you could use Spring Security OAuth2, see OAuth 2 Developers Guide:
Accessing Protected Resources
As a general rule, a web application should not use password grants, so avoid using ResourceOwnerPasswordResourceDetails if you can in favour of AuthorizationCodeResourceDetails. If you desparately need password grants to work from a Java client, then use the same mechanism to configure your OAuth2RestTemplate and add the credentials to the AccessTokenRequest (which is a Map and is ephemeral) not the ResourceOwnerPasswordResourceDetails (which is shared between all access tokens).
Or you could update to Spring Security 5.2.x, see Spring Security Reference:
11.2 OAuth 2.0 Client
The OAuth 2.0 Client features provide support for the Client role as defined in the OAuth 2.0 Authorization Framework.
At a high-level, the core features available are:
Authorization Grant support
Authorization Code
Refresh Token
Client Credentials
Resource Owner Password Credentials
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 a legacy desktop application that communicates with a Spring Boot server (latest version 2.2.2.RELEASE). I'm using OAuth2 for authentication (provided by spring-boot-starter-oauth2-client). I want to avoid changing the client because is a legacy application. It is capable of collecting the credentials and start the session via HTTP Basic Authentication, and then keep the cookies for the session in the following requests.
Given this scenario, I think best option is to make use the OAuth2 Resource Owner Password Credentials grant. With this, we can exchange the collected credentials by the OAuth2 Tokens. We have two options:
Option 1:
Modify the client application to use the access tokens via the Authorization header. This will require to make an initial call to the Authorization Provider to exchange the collected credentials by the tokens.
Option 2:
Keep using the Spring session and store the information about the OAuth client in the server.
I found this project ALMOST does that: https://github.com/jgrandja/spring-security-oauth-5-2-migrate. It has a client (messaging-client-password) defined with authorization-grant-type: password which will activate the OAuth2 Resource Owner Password Credentials grant in Spring Boot.
It creates an OAuth2 client and stores its information in the session, then Spring is able to use that client in further requests. The problem with this project is it seems to only work as when the OAuth client is used to make HTTP requests (e. g. an endpoint that makes a call to another service) and not provide authentication to the controller. You can find more information about this in here:
Spring Security 5.2 Password Flow
Github related issues: link1, link2, link3
Exception thrown when we try to use the password client as authentication
The natural idea to overcome this is to implement a proxy and use the OAuth2 client in the requests. Well, Spring already offers a proxy solution, the Spring Cloud Gateway. But I don't know to accomplish that with this setup.
Any insights? Am I thinking correctly or should I follow a different approach?
I have two Spring applicatons and I need to authenticate first application in another apllication. Its server-to-server communication and authentication. Is OAuth suitable for this or there is another way to rosolve it?
Yes, OAuth 2.0 is suitable for authenticating other applications (clients) with its Authorization Server.
OAuth 2.0 Client Credentials grant type does that. For more information Check out these links: https://www.rfc-editor.org/rfc/rfc6749#section-4.4 and https://oauth.net/2/grant-types/client-credentials/
Spring provides an API (OAuth2RestTemplate) to automate client authentication process.
I'm using Spring SAML2.0 For SSO and Identity server as WSO2 5.4.0
I have done that with the SAML single sign on and now I want to define the role of the USERS and according to the roles of the user they can access the some sort of functionality in my application.
Ideally the User credential is stored in wso2 identity server and I defined there the role of the user.
When I fetch the assertion xml which is coming from wso2 IDP I can't find the role of the users.
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.