I am developing an app secured with Spring Oauth2, password flow.
But I'm still confused about difference between UserDetailService and ClientDetailsService flows in Spring.
As I understand from OAuth2 specification, client and user are different entities. Client has clientId, clientSecret and some grants, and User has username, password and also some grants.
Multiple users use the same client (mobile app or web browser in my case).
So I need to authenticate some user and provide it with an access token.
I have implemented both UserDetailsService and ClientDetailsService (with all needed infrastructure: AuthorizationServerConfigurerAdapter and ResourceServerConfigurerAdapter) and during authentication I see, that username from request is passed as clientId into clientDetailsService and
as username into userDetailsService.
But I thought it should be more complex process like for authentication request client should provide both client credentials and user credentials so then I can verify client (is it registered in my system) and its grants then verify user and its grants and then return an access token.
My questions:
Do I understand the process correctly?
Are client grants and user grants of the same meaning?
What classes should I customize to separate verification of client and user credentials?
Solution is stupid simple.
The client and the user are really different entities
To obtain access token you need to complete basic authentication with Base64 encoded client credentials in header and username/password of the user in params.
Header pseudocode:
Basic Base64("client_id:client_secret")
Params:
username=username, password=password, grant_type=password
This will return you access_token, refresh_token and some extra info.
Related
I have a spring-boot application and I am using keycloak to authenticate users. I am planning to make an endpoint in my application that waits a username and a password, it logs-in to keycloak and if the username/password is valid ask for an access token and give it back to the user.
How can I make this log-in to keycloak?
As I see I need to have a public client to make my keycloak use username/password, but this does not contain any resource_id so I need an access_token from a confidential client.
Should I ask for an access_token from the public client, and if the response code is 200 (so the login is successful) then send another request to the confidential client to get back an access_token that is actually working?
Thanks in advance.
I am planning to make an endpoint in my application what waits a
username and a password, it logs into the keycloak and if the
username/password is valid ask for an access token and give it back to
the user.
If we assume that
the Spring App is configured correctly;
the Keycloak client that the users will be authenticating against uses Authorization Code Flow (i.e., Standard flow Enabled on Keycloak), or even better Authorization code flow with PCKE
then when a user logins into your app, the user gets redirected to Keycloak for authentication. The user is redirected (probably) back to your app (if the authentication is successful), and your app receives, among others, an access token. That access token can then be used to perform actions on behalf of the authenticated user.
As I see I need to have a public client to make my keycloak use
username/password, but this does not contain any resource_id so I need
an access_token from a confidential client.
From the RFC 6749 OAuth 2.0 specification one can read:
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
Since you are neither using a pure web browser application nor a mobile phone but instead a spring-boot application with a secure backend, you should use a confidential client.
You are mixing up concepts if you mean that you want to use "Resource Owner Password Credentials Grant" (i.e., Direct Access Grants Enabled in Keycloak). You can still used with your application without having to use a confidential client. With a public client the request for a token from Keycloak looks like:
POST -d "client_id=<client_id>"
-d "username=<username>"
-d "password=user_password"
-d "grant_type=password"
<KEYCLOAK_HOST>/auth/realms/<REALM_NAME>/protocol/openid-connect/token>
with a confidential client:
POST -d "client_id=<client_id>"
-d "client_secret=<client_secret>"
-d "username=<username>"
-d "password=user_password"
-d "grant_type=password"
<KEYCLOAK_HOST>/auth/realms/<REALM_NAME>/protocol/openid-connect/token>
you got the extra field -d "client_secret=<client_secret>".
Bear in mind, however, that:
The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged
application. The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.
I'm currently building a microservice backend with Spring Boot, Zuul as API Gateway and Keycloak as Authentication and Identity Provider.
For my frontend I'm currently using Angular as an SPA with the Authorization Code Grant.
The API Gateway should validate each request (if the user is authorized) via Keycloak before sending it to the microservice.
Each microservice ( ResourceServer) should be able to get the user information for the current request by using the introspection endpoint.
What would be the correct way to implement this, or is this even a bad design and I'm on the wrong way?
Typically, you have two options:
JWT given to client: The client (Angular SPA in your case) authenticates and receives the JWT. The JWT token can be verified by an party using the Keycloak public key. It also contains a lot of user information.
JWT given to back-end: The client is given the temporary authorization code grant. It is forwarded to a backend system, which exchange it for the JWT. The backend system will need to create a user session, store the JWT in the user session and use a session ID cookie (or a similar mechanism) to match the client to the session.
The proposed architecture is a mix of both worlds. Option 1 would be more natural.
Option 1: The client authenticates with Keycloak and gets the JWT. It then attaches the JWT to each request. Zuul can check that the JWT is signed by the trusted Keycloak instance and that it has not yet expired (without contacting Keycloak). The microservice can do the same. If more than the basic user information is needed, the microservice can contact Keycloak.
Option 2: I can't tell you if option 2 is possible with Zuul. Let's assume that it is. If so, the gateway would redirect unauthenticated requests to Keycloak. Once the client has received the authorization code grant, it is redirected to the API gateway. The API gateway then contacts Keycloak to exchange the code for the JWT and saves it in a session. The client is given a session ID. When a request is forwarded to the micro service, the JWT is added to the request. The client never sees the JWT.
These descriptions assume that you are using Open ID Connect, which is supported by Keycloak. If you use an OAuth 2 setup, most things still apply but a few details are more complicated, e.g. instead of the JWT containing all the information you get an opaque token that can only be validated against an introspection endpoint.
I've a Keycloak server and I want to auth via http Ajax request, sending username + email to login. and signup new user. is that possible to create standalone web app to authorize user?
Even if it's not a good practice you can do that by enabling Direct Grant Access for your client, look for "Resource Owner Password Credentials Grant" in the documentation https://keycloak.gitbooks.io/documentation/content/server_admin/topics/sso-protocols/oidc.html
I have read and implemented my own Auth server following this tutorial from Spring. There are multiple SSO providers - Facebook, Github and a custom auth server. In this tutorial, the auth server contains the handling of other SSO providers.
I have a separate resource server that links to my auth server using the following properties:
security.oauth2.resource.userInfoUri=http://localhost:9000/user
I am able to get the token from my auth server using a cUrl command:
curl acme:acmesecret#localhost:9000/oauth/token -d grant_type=password -d username=user -d password=...
{"access_token":"aa49e025-c4fe-4892-86af-15af2e6b72a2","token_type":"bearer","refresh_token":"97a9f978-7aad-4af7-9329-78ff2ce9962d","expires_in":43199,"scope":"read write"}
But what I fail to understand is how can I use the other SSO providers to get such token as well from the auth server? The resource server should not care how did I get the token and whether I am authenticated using Facebook or my custom auth server. It should simply ask the auth server what is the Principal (logged user) and then decide which resources to show him, right?
I don't have any UI and this will be backed for a mobile application so I need to udnerstand how to handle the authentication using REST reqeusts.
If I understand your question correctly,
how can I use the other SSO providers to get such token as well from
the auth server?
This custom Auth server is abstracting out your interaction with FB or Github and issuing you it's own token. The token that your custom Auth server spitting out is not an FB or Github token, it's a token generated by your custom Auth server (After authenticating with FB/Github token).
Then why do we need FB/github?
How else your custom Auth server can identify a person, It sure can use user Id and Password; consider 'login with FB' as another nice option it gives to the user.
How to add other SSO providers like digitalocean in addition to FB and github?
Just do the same as we did for FB and Github (register a client id with digital ocean and then in auth server application, Add client Id and secret in the properties/yaml file etc)
The resource server should not care how did I get the token and
whether I am authenticated using Facebook or my custom auth server. It
should simply ask the auth server what is the Principal (logged user)
and then decide which resources to show him, right?
Yes, your understanding is correct.
Edit (To answer question asked in the comment)
But lets say I log in with Facebook through my Auth server. Where do I
find the token that I can use with the Resource server? Let's say I
have a RestClient and want to make a request to obtain some resource
belonging to a user which went through the Facebook auth process via
my auth server. Where do I find the token to use?
If that's a requirement, I think you can use this example instead; you may not need a custom auth server as such. Whole point of having custom auth server is abstracting out the interaction with FB or github.
Or
If you still want to go with custom auth server direction, then expose an endpoint from Auth server (which will get you the resources you need from FB) and then make use of that from your resource server.
I am using Spring Security Oauth2 for generating access token. When I use password as grant type, I send a post request as
http://localhost:8085/oauth/token?grant_type=password&client_id=ws&client_secret=secret&scope=read+write&username=david#abc.com&password=abc#123
I don't want to send the username and password in the URL.
I checked source code of TokenEndPoint.java but couldn't find much. I know that we can use HTTPS and encrypt the username and password.
I just want to know if there is any way to send username and password in headers.
I hope this helps you and meets your requirement.
Source: https://github.com/spring-projects/spring-security-oauth/blob/master/docs/oauth2.md
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).
OAuth2RestTemplate example in Git Hub
url: https://github.com/mariubog/oauth-client-sample