How to get Keycloak client_id and client_secret from server to client - rest

Actually I have a server (customer server) from where I would like to fetch some parameters and its values for NE configuration through REST API.
To achieve the above task I need to follow the below steps:
1) Creating a Keycloak client id and generating a client secret for the respective client id created. (One time step can be done manually in Keycloak admin GUI)
2) Using the client id and client secret - generating an access token.
3) Using access token and retrieving the expected parameters
Here I have found the methods and API URLs to get the expected parameters and its values (Step 3 is done), But to make the initial connection (Step 2) between my server (Client-From where I am making the REST calls) and customer server (Server-Which responds to my API calls) I need to find some method to exchange the client id and client secret from source server to client server.
My development environment has some limitation that I cannot directly use the client id and client secret hard coded in it.
So, My doubts are
1) In general will the customer shares the client id and client secret to developers to get connected to the authentication server ?
2) Will the client id and client secret gets stored anywhere in the server (some default location) so that i can login to the server and get these data directly to generate the access token?
3) Is there another way to get the client id and client secret from source server.

Related

Keycloak REST API 401 when using custom client with service account

we want to access the Keycloak (Version 10) REST API from one of our backend services. To authenticate, we have setup the followings:
new clients within our realm
enabled service account for that client
assigned all [1] roles of “realm-management” to the services account
Accessing the API, e.g. fetching a selected user always results in a 401 response.
Steps to make the requests are:
Retrieve access_token from https://my-keycloak.com/auth/realms/my-realm/protocol/openid-connect/token using grant_type=client_credentials + Client ID + Client Secret
Fetch user from https://my-keycloak.com/auth/realms/my-realm/users/some-user-id-4711
using the Authorization: Bearer $ACCESS_TOKEN with the Token from step 1.
My Question: Is it even possible to use a custom client or do we have to stick to login via admin-cli? How would we need to configure the custom client, to grant access to the REST API.
Thanks,
Martin
[1] Simply setting all roles for the sake of testing, regardless that we only want to read data in the end.

Keycloak authentication: how can a external user get an token without exposing client secret

I have a query about how keycloak is supposed to be working with client without GUI access.
Basically I have:
A keycloak server configured with a realm, clients(Access type confidential) and Users
A server application with a GUI that also provide API, secure with keycloak (client, user, blablabla)
This is kind of working already as I am able to log on the GUI, have the redirect, etc..
Even accessing the APIs works well, when I have access to a GUI: I log on my UI, follow the redirect and get my UI to display the token. The the human (to differentiate the user from an application), can use the token in any API client.
In this context the user never sees the client secret, which is instinctively the right way. (note that I am very opened to people telling me my instinct is wrong!)
What I am NOT able to do so far is to find the way a server application (without GUI) can get a valid token?
The authorization_endpoint, as far as I understand it, requires both the client id and the client secret) to get a token, which I would rather avoid: I don't think giving my client secret to all my "customers" is the proper way to do it.
Alternatively I could create an API on my client that woudl ask for user credential and ask for the token in its behalf, but that would expose the clients credentials to my application, which is against the whole concept!
I tried setting my client Access type as public, but when I use the API call below I also get a error:
POST /auth/realms/realmname/protocol/openid-connect/tokenAPI
'grant_type=client_credentials'
'client_id=client_id'
'username=username'
'password=password'
{
"error": "unauthorized_client",
"error_description": "Public client not allowed to retrieve service account"
}
Would anyone know how this is supposed to be done ?
Thanks in advance.
Max
(...) A server application (without GUI) can get a valid token... typically using the Client Credentials flow.
But we would define in this case a dedicated Client for your server (client?) application to authenticate against. The returned token (not bound to a specific user) will serve for authorizations on allowed applications (i.e. your classic GUI or API clients).
So, basically you should (in very short):
define a specific confidential Client in your Keycloak
add the desired applications (or other Clients) to the Client Scope(s). Those you want to authorize transitively from this Client.
authenticate against this Client with Client Credentials flow (given the token endpoint, client id, credentials, scope)
ensure that you are authenticating through TLS and that parameters are included in request body (and not in headers - for enhanced privacy)
further harden security of your Client(s)
When you do not want anymore this particular server (client?) application to access your applications, you can change the corresponding "authentication" Client's secret/credentials or simply delete it.
"I don't think giving my client secret to all my "customers" is the proper way to do it."
You are right and the proposed method above strictly avoids that. Each customer would have its own credentials.
EDIT
(adding more details)
By performing as above, you would end up with the following scheme:
Flow Keycloak Server
C/S app. or Customer X <--- Client Creds ---> Auth. Client X
--- Access Token ---> Appl. Client <--> Appl. Server
C/S app. or Customer Y <--- Client Creds ---> Auth. Client Y
--- Access Token ---> Appl. Client <--> Appl. Server
Browser users <--- Standard ------> Appl. Client <--> Appl. Server
Note: this is not a detailed flow chart. Arrows mostly show relationships here.
Finally, please note that the terminology may differ a little here, but the proposed method is basically the same that Google uses. So you may aswell take some inpiration from there:
https://developers.google.com/identity/protocols/oauth2
I just had the same problem some weeks ago
In my case, I have a backend API and a frontend application that the users can use.
Eventually, I can't share the client_secret to the frontend application.
So here is my solution:
On keycloak, create a client (ex front_end_client) with grant type public
This client is going to be used by the frontend application to authenticate users using implicit flow (with PKCE will be more secure)
On keycloak, create a second client (On the same REALM as the first client) with grant type confidential, this client is going to be used by the backend API
Now, this is how it works:
Frontend app authenticate users and get the access token (Using the font_end_client)
The frontend app sends this token for every request to the backend
Backend app verify this token, and can retrieve permissions from it

Validate oAuth 2 access token in APIGEE without VerifyOAuthTokens policy

We are using Apigee as our Authorization Server (AS) and we have a few Spring Restful services deployed in IBM Bluemix public cloud which acts as our Resource server (RS).
Each of the services has an equivalent proxy service configured in Apigee. For the proxy services, we have configured the VerifyOAuthTokens policy to verify the token passed by the user and return an error if invalid token is passed
The problem is, since our RS is in the public cloud (no plans or need of moving to a dedicated or private cloud) the api endpoints are open and can be invoked by anyone who knows the url.Though the expectation is everyone should call the apis via APIGEE proxies but we cannot force that since we are in public cloud and there are no options of opening ports coming from apigee or something. We would like to take the following approach to secure the api endpoints.
Accept the Authorization header for each call
Take the token and call a validate token service in Apigee
For 2, We are not able to find an APIGEE api which can validate an access token similar to say googles
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg
or Github's
GET /applications/:client_id/tokens/:access_token
Is there actually an external APIGEE service to validate a token?
If not, what would be the best way to make sure that only valid users with valid tokens can access the apis?
Thanks,
Tatha
Did you look at this post in the Apigee Community: Using third-party OAuth tokens
We did something similar to this but not using oauth tokens. We used Apigee to do a callout to a third party IDP (identity provider). The 3rd party IDP wasn't able to generate tokens but exposed a web service to authenticate the user. If the user was authenticated successfully (based on interpreting the result received back from the target endpoint webservice), then you tell Apigee that it was successful by setting the external authorization status to true (step #2 in the link).
NOTE: this has to be done inside an Assign Message Policy step PRIOR to the GenerateAccess token operation. Apigee interprets this as a successful authorization and then can generate a valid oauth token that the caller can then send along to access the protected API.

Oauth2: how should the resource server know if the access token is valid?

I'm implementing an Ouath2 authentication with Spring for our mobile API. So far it works but I don't know how I should keep the resource server separate. So I have an auth server which gives out tokens and refresh tokens using the password grant-type. Meaning the user would log into the mobile app, which sends the auth server the client id/client secret along with the user's
credentials, which results in an access token and a refresh token for the user with the appropriate (ROLE_USER) privileges. Another web based client is for the admins who do the same and get the ROLE_ADMIN privilege etc.
This works well so far.
Now if any client sends a request to the resource server what should happen? Should the resource server check the token's validity? If so in what way? Or should the auth server copy the token into the resource-server's database?
If you #EnableResourceServer you get a filter that checks access tokens. It needs to share a TokenStore with the auth server. That's about it to get something working.

not recognized cas ticket

I have a REST api in my web application where I get cas ticket generated by another webapp.
That webapp intern use cas20proxyticketvalidator to validate the ticket. Therefore, I also use Cas20ProxyTicketValidator in my custom filter to validate the ticket.
But it always give me following error:
ticket = ST-148008-jWXKeEdHkxmuktvYqXF6-cas
org.jasig.cas.client.validation.TicketValidationException:
ticket 'ST-148008-jWXKeEdHkxmuktvYqXF6-cas' not recognized
at org.jasig.cas.client.validation.Cas20ServiceTicketValidator.parseResponseFromServer(Cas20ServiceTicketValidat
or.java:86)
at org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidator.java
:217)
Why my ticket is not recognized?
The way that cas validates tickets is:
Your client (or the other web app) requests a ticket from the relay
server for a particular service, for example case
http%3A%2F%2Fwww.mywebapp.com
The cas server generates a row that stores the user's ssoguid, the service and the ticket. It returns the ticket to the client (or
other web app)
The client (or other webapp) sends the ticket to your server
Your server then sends a request to the serviceValidate endpoint of the cas server with the ticket and the service,
http%3A%2F%2Fmywebapp.com
The cas server uses the ticket and service pair to find the row it generated. If it finds the row it: a) checks to see if the
service is real by sending a request to that url b) deletes the row
to invalidate the ticket after this validation check c) it returns
the user attached to the ticket to your server. Now the ticket can
not be validated again.
The problem you are experiencing could arise for several reasons:
The ticket has already been validated (I don't think that is the
case for you)
The service you send when generating the ticket is different to the service you send to the serviceValidate endpoint (they have to
be identical). (I would guess that this is the problem you are
experiencing, especially if another webapp generated the ticket. The
cas server would have http%3A%2F%2Fotherwebapp.com on file but would
be trying to find a row with http%3A%2F%2Fmywebapp.com, which
doesn't exist because you didn't create it)
The service sent can
not be contacted by the relay server (I'm not exactly sure of the
details about how this works or exactly when the check it done but
it is recommended that you use a service that can be contacted)
Check the serviceUrl generated, so change the log level for package org.jasig.
With SpringBoot, in the application.properties add
logging.level.org.jasig=DEBUG
In the console
org.jasig.cas.client.util.CommonUtils : serviceUrl generated: https://xxx
Verify and adapt your cas.client-host-url in the application.properties
## CAS[2.0]
cas.server-url-prefix=https://cashost.com/cas
cas.server-login-url=https://cashost.com/cas/login
cas.client-host-url=xxx
cas.validation-type=CAS
Be careful with cas.client-host-url, no slash at the end of url.
Don't forget mvn clean package after modifying .properties