Introspection Endpoint of KeyCloak server - oauth-2.0

I am trying to explore features of KeyCloak server and want to get information about access token by using /openid-connect/token/introspect endpoint.
So, I am sending next request to this endpoint
curl -v --data "token_type_hint=access_token&client_id=product-
app&username=user&token=MY ACCESS TOKEN"
http://localhost:8080/auth/realms/springdemo/protocol/openid-
connect/token/introspect
So this is what I have as a response:
{"error":"invalid_request","error_description":"Client not allowed."}*
Connection #0 to host localhost left intact
and this is what I see in KeyCloak's logs:
12:00:18,045 WARN [org.keycloak.events] (default task-13)
type=INTROSPECT_TOKEN _ERROR,
realmId=springdemo, clientId=product-app, userId=null, ipAddress=127.0.0
.1, error=invalid_request, detail='Client not allowed.',
client_auth_method=client-secret
So, I can't get it - how should I properly make request to keycloak in this case regarding that product-app has public access. Please, explain!

It seems like you are not able to use /openid-connect/token/introspect endpoint when your client has public access type.
So, switch to the CONFIDENTIAL ACCESS TYPE and use
curl -v --data "client_secret=YOUR_SECRET9&client_id=product-
app&username=user&token=YOUR_TOKEN"
http://localhost:8080/auth/realms/springdemo/protocol/openid-
connect/token/introspect
It works fine.

Related

how to use\connect to sonatype nexus docker registry v2 api in a web application?

I have a private sonatype nexus repository manager OSS 3.25.1-04 container running on a vm (with nginx routing from docker.io to repo manager url) that contains a few repositories, one of them is a docker registry.
I want to use the docker registry v2 api from a react app to get a listing for the docker images in the repository and maybe some more metrics about the repo and its contents.
I tried calling the api directly: https://nexus3:8083/v2/_catalog but got 401 UnAuthorized in the response when checking the devtools network tab
Then to login to the api I tried using https://auth.docker.io/token?service=registry.docker.io&scope=repository:samalba/my-app:pull,push when substituting samalba/my-app with my own registry and example docker image. I know this link is to get token for only this image couldn't find one for the entire api (it didn't work anyway)
Could use some help on how to connect to the api\get jwt token and using it or how to use the api with http instead
A few things may be going on. First, try just using basic authentication and seeing if that works. Additionally, you may need to set some additional headers to connect to nexus / sonatype. Here is an example with curl:
curl -H "Accept: application/vnd.docker.distribution.manifest.v2+json" -H "Content-Type: application/json" -H "User-Agent: docker/20.10.14" -u username:password -i https://nexus3:8083/v2/_catalog
Note the user agent field -- i've run into issues where the authentication layer is filtering out for the docker user agent.
If that still doesn't work, then the next thing you can look for is to see if the registry response with the header www-authenticate. This means you will need to first authenticate with that service to retrieve a Bearer token, and then you can pass that back to the registry using the Authorization header instead of basic auth.
Hope that helps.

401 error when trying GET request to Hawkbit Server with Gateway Security Token

Q1:
I'm running a Hawkbit server on localhost in a docker container and activated the option "Allow a gateway to authenticate and manage multiple targets through a gateway security token" in the settings of the web UI that I access via http://localhost:8080/.
Now I'm using Postman to send a GET request to http://localhost:8080/default/controller/v1/25 with the header
key: GatewayToken, value: <The gateway token shown in the Hawkbit web UI>
Using this header, I'm supposed to be able to authenticate my Postman client against the Hawkbit server (compare e.g. https://www.eclipse.org/hawkbit/concepts/authentication/), however I'm always getting a "401 Unauthorized" response.
Even if I enable "Allow targets to download artifacts without security credentials" which should enable any client to get a ressource even without authentification, I get a 401.
What am I doing wrong?
Q2:
The Hawkbit server is running in Docker started via "docker-compse up -d" as described here: https://www.eclipse.org/hawkbit/gettingstarted/
In order to solve the problem of Q1, I wanted to check the output of Hawkbit inside the container, but I'm not too familiar with docker and couldn't find out how. I was able to get inside the conainer using
docker exec -it docker_hawkbit_1 /bin/sh
which bring me into the container's file system at /opt/hawkbit. But that's not what I was looking for. How can I see the log/output of the Hawkbit/Spring Boot application running inside the container?
Q1:
The key of the request should not be GatewayToken, but Authorization. The header of the request will then look as follows:
key: Authorization, value: GatewayToken <token>
Q2:
Try the following command to see the logs:
docker logs -f docker_hawkbit_1

keycloak token introspection always fails with {"active":false}

I'm kind of desesperate to make this keycloak work. I can authenticate but for some reason, my token introspection always fail.
For example if I try to authenticate:
curl -d 'client_id=flask_api' -d 'client_secret=98594477-af85-48d8-9d95-f3aa954e5492' -d 'username=jean#gmail.com' -d 'password=superpassE0' -d 'grant_type=password' 'http://keycloak.dev.local:9000/auth/realms/skilltrock/protocol/openid-connect/token'
I get my access_token as expected:
{
"access_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJnLVZJQ0VETnJ4NWRfN1pWQllCTC1tNDdTZWFNT3NDVlowSFdtZF9QQkZrIn0.eyJqdGkiOiIwNTBkYWI5MS1kMjA5LTQwYjctOTBkOS1mYTgzMWYyMTk1Y2MiLCJleHAiOjE1NDQ1MjIyNDEsIm5iZiI6MCwiaWF0IjoxNTQ0NTIxOTQxLCJpc3MiOiJodHRwOi8va2V5Y2xvYWsuZGV2LmxvY2FsOjkwMDAvYXV0aC9yZWFsbXMvc2tpbGx0cm9jayIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI3NDA0MWNkNS1lZDBhLTQzMmYtYTU3OC0wYzhhMTIxZTdmZTAiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJmbGFza19hcGkiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiJiOGI0MzA2Ny1lNzllLTQxZmItYmNkYi0xMThiMTU2OWU3ZDEiLCJhY3IiOiIxIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19LCJzY29wZSI6ImVtYWlsIHByb2ZpbGUiLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsIm5hbWUiOiJqZWFuIHBpZXJyZSIsInByZWZlcnJlZF91c2VybmFtZSI6ImplYW5AZ21haWwuY29tIiwiZ2l2ZW5fbmFtZSI6ImplYW4iLCJmYW1pbHlfbmFtZSI6InBpZXJyZSIsImVtYWlsIjoiamVhbkBnbWFpbC5jb20ifQ.x1jW1cTSWSXN5DsXT3zk1ra4-BcxgjXbbqV5cjdwKTovoNQn7LG0Y_kR8-8Pe8MvFe7UNmqrHbHh21wgZy1JJFYSnnPKhzQaiT5YTcXCRybSdgXAjnvLpBjVQGVbMse_obzjjE1yTdROrZOdf9ARBx6EBr3teH1bHMu32a5wDf-fpYYmHskpW-YoQZljzNyL353K3bmWMlWSGzXx1y7p8_T_1WLwPMPr6XJdeZ5kW0hwLcaJVyDhX_92CFSHZaHQvI8P095D4BKLrI8iJaulnhsb4WqnkUyjOvDJBqrGxPvVqJxC4C1NXKA4ahk35tk5Pz8uS33HY6BkcRKw7z6xuA",
"expires_in":300,
"refresh_expires_in":1800,
"refresh_token":"eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJlYmY4ZDVlOC01MTM4LTRiNTUtYmZhNC02YzcwMzBkMTIwM2YifQ.eyJqdGkiOiI3NWQ1ODgyMS01NzJkLTQ1NDgtOWQwYS0wM2Q3MGViYWE4NGEiLCJleHAiOjE1NDQ1MjM3NDEsIm5iZiI6MCwiaWF0IjoxNTQ0NTIxOTQxLCJpc3MiOiJodHRwOi8va2V5Y2xvYWsuZGV2LmxvY2FsOjkwMDAvYXV0aC9yZWFsbXMvc2tpbGx0cm9jayIsImF1ZCI6Imh0dHA6Ly9rZXljbG9hay5kZXYubG9jYWw6OTAwMC9hdXRoL3JlYWxtcy9za2lsbHRyb2NrIiwic3ViIjoiNzQwNDFjZDUtZWQwYS00MzJmLWE1NzgtMGM4YTEyMWU3ZmUwIiwidHlwIjoiUmVmcmVzaCIsImF6cCI6ImZsYXNrX2FwaSIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6ImI4YjQzMDY3LWU3OWUtNDFmYi1iY2RiLTExOGIxNTY5ZTdkMSIsInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJvZmZsaW5lX2FjY2VzcyIsInVtYV9hdXRob3JpemF0aW9uIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJlbWFpbCBwcm9maWxlIn0.omhube2oe79dXlcChOD9AFRdUep53kKPjD0HF14QioY",
"token_type":"bearer",
"not-before-policy":0,
"session_state":"b8b43067-e79e-41fb-bcdb-118b1569e7d1",
"scope":"email profile"
}
But if I try to introspect the access_token like given below, keycloack return always {"active":false}. I really don't understand this behavior.
curl -X POST -u "flask_api:98594477-af85-48d8-9d95-f3aa954e5492" -d "token=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJnLVZJQ0VETnJ4NWRfN1pWQllCTC1tNDdTZWFNT3NDVlowSFdtZF9QQkZrIn0.eyJqdGkiOiIwNTBkYWI5MS1kMjA5LTQwYjctOTBkOS1mYTgzMWYyMTk1Y2MiLCJleHAiOjE1NDQ1MjIyNDEsIm5iZiI6MCwiaWF0IjoxNTQ0NTIxOTQxLCJpc3MiOiJodHRwOi8va2V5Y2xvYWsuZGV2LmxvY2FsOjkwMDAvYXV0aC9yZWFsbXMvc2tpbGx0cm9jayIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI3NDA0MWNkNS1lZDBhLTQzMmYtYTU3OC0wYzhhMTIxZTdmZTAiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJmbGFza19hcGkiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiJiOGI0MzA2Ny1lNzllLTQxZmItYmNkYi0xMThiMTU2OWU3ZDEiLCJhY3IiOiIxIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19LCJzY29wZSI6ImVtYWlsIHByb2ZpbGUiLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsIm5hbWUiOiJqZWFuIHBpZXJyZSIsInByZWZlcnJlZF91c2VybmFtZSI6ImplYW5AZ21haWwuY29tIiwiZ2l2ZW5fbmFtZSI6ImplYW4iLCJmYW1pbHlfbmFtZSI6InBpZXJyZSIsImVtYWlsIjoiamVhbkBnbWFpbC5jb20ifQ.x1jW1cTSWSXN5DsXT3zk1ra4-BcxgjXbbqV5cjdwKTovoNQn7LG0Y_kR8-8Pe8MvFe7UNmqrHbHh21wgZy1JJFYSnnPKhzQaiT5YTcXCRybSdgXAjnvLpBjVQGVbMse_obzjjE1yTdROrZOdf9ARBx6EBr3teH1bHMu32a5wDf-fpYYmHskpW-YoQZljzNyL353K3bmWMlWSGzXx1y7p8_T_1WLwPMPr6XJdeZ5kW0hwLcaJVyDhX_92CFSHZaHQvI8P095D4BKLrI8iJaulnhsb4WqnkUyjOvDJBqrGxPvVqJxC4C1NXKA4ahk35tk5Pz8uS33HY6BkcRKw7z6xuA" http://localhost:9000/auth/realms/skilltrock/protocol/openid-connect/token/introspect
return
{"active":false}
Where I am wrong? I'm totally lost
You need to make sure that you introspect the token using the same DNS hostname/port as the request. Unfortunately that's a not widely documented "feature" of Keycloak...
So use:
curl -u "flask_api:98594477-af85-48d8-9d95-f3aa954e5492" -d "token=<token>" http://keycloak.dev.local:9000/auth/realms/skilltrock/protocol/openid-connect/token/introspect
A legacy alternative is to send a Host header with the introspection request which matches the frontend host where the token was obtained. That I have tried, I can confirm that it works. It requires configuration of two URLs for the introspecting protected resource, though.
Since Keycloak 8 it is also possible to use the OpenID Connect Discovery as described in https://issues.redhat.com/browse/KEYCLOAK-11728 and the attached design document.
The latter solution involves two things:
Keycloak needs to know the frontend URL used for token retrieval by clients; that can happen at start time as described in the server installation (-Dkeycloak.frontendUrl or standalone.xml) or when definining a realm through its Frontend URL Option in the Keycloak Management UI. The Keycloak docker container supports the environment variable KEYCLOAK_FRONTEND_URL for this. Note that the frontendUrl needs to include the basePath where Keycloak is running (/auth by default, adjust as needed).
Optionally, the protected resource can use OIDC discovery to determine the introspection URL. Either use the Keycloak Java Adapter >=v8 which has built-in support for OIDC Discovery or verify if your protected resource does. See the related PR on the Keycloak Java Adapter for details.
When a protected resource uses the internal discovery endpoint http://keycloak:8998/auth/realms/myrealm/.well-known/openid-configuration, it will find the correct internal introspection endpoint:
{
"issuer": "http://localhost:8998/auth/realms/myrealm",
"authorization_endpoint": "http://localhost:8998/auth/realms/myrealm/protocol/openid-connect/auth",
"token_endpoint": "http://keycloak:8080/auth/realms/myrealm/protocol/openid-connect/token",
"token_introspection_endpoint": "http://keycloak:8080/auth/realms/myrealm/protocol/openid-connect/token/introspect"
}
Using the discovery endpoint is not required. If you just need to introspect an incoming token with Keycloak, you can directly use the introspection endpoint.
The introspect endpoint can also return {"active":false} if a session associated with that token doesn't exist in Keycloak. For example, if you create the token, restart keycloak and then call introspect.
As mentioned earlier the same domain should be used when obtaining and introspecting the token.
For me, I was using the localhost to obtain the token and 127.0.0.1 to introspect the token.

cURL Docker registry authorization error "authentication required"

I have set up docker auth server using cesanta and used mongodb for ACL everything works fine. Only issue is when I am doging curl to my registry catalog I got UNAUTHORIZED.
curl -Lk https://example.docker.com:5000/v2/_catalog
I am getting below error:
{"errors":[{"code":"UNAUTHORIZED","message":"authentication
required","detail":[{"Type":"registry","Class":"","Name":"catalog","Action":"*"}]}]}
You need to acquire a bearer token to be used as header for authentication. Here is a detail doc on how to get it https://github.com/docker/distribution/blob/master/docs/spec/auth/token.md

Connection refused in wso2 playground2 sample

I am doing playground2 sample of wso2 from this post. It is generating access token but having problem when I am accessing UserInfo.
It's saying connection refused. I am using wso2is-5.0.0
thank you
You can also use below curl command for call userinfo endpoint and if you need more details you can use this URL.
curl -k -H "Authorization: Bearer <paste_access_token>" https://localhost:9443/oauth2/userinfo?schema=openid
Plus you need to adding claims in OAuth service provider side and get more details in this offcial WSO2 document.

Resources