userinfo_endpoint

[annaitzhaki]

hi, is there a way to add fake data to userinfo_endpoint?
email, name etc.

[ybelMekk]

Hi!

have you tried to configure custom claims?

ref: https://github.com/navikt/mock-oauth2-server#json_config

[github-actions]

This issue is stale because it has been open for 60 days with no activity.

[gpsmit]

Sorry to reopen this, we are running into the same issue.
I think the problem is that /userinfo is a simple GET without request parameters, so therefore none of the custom claims are getting matched on the /userinfo call

[tommytroen]

Sorry to reopen this, we are running into the same issue. I think the problem is that /userinfo is a simple GET without request parameters, so therefore none of the custom claims are getting matched on the /userinfo call

@gpsmit If you do a GET to the /userinfo endpoint you will get the claims that are inside the token you use for auth (i.e. the bearer token in the authorization header), so you can use requestmapping to include the claims you want when you obtain that token.

[gpsmit]

Maybe i understand the json config file usage incorrectly, but that returns a certain configured request when the request matches specific parameters in the call right?
For instance, the mock server would return [email protected] when an endpoint is called with parameter scope=email right?
say: /endpoint?scope=email.

{
    "interactiveLogin": true,
    "httpServer": "NettyWrapper",
    "tokenCallbacks": [
        {
            "issuerId": "issuer1",
            "tokenExpiry": 120,
            "requestMappings": [
                {
                    "requestParam": "scope",
                    "match": "email",
                    "claims": {
                        "email": "[email protected]"
                    }
                }
            ]
        }
    ]
}

We have a spring boot app that uses the oauth2 client to authenticate a user with oauth2 scopes of openid,profile,email the spring boot oauth2 flow automatically goes to the /userinfo endpoint after authentication to retrieve the user details, but no claims mapping from the json.config file is ever returned by the mock server.

EDIT: I see that the token requests are transformed to a http request before the request mappings are evaluated, still im not sure how to mock /userinfo data, config as above does not seem to work. Are tokens presented to the /userinfo endpoint also transformed and evaluated in the same way as token requests?

[gpsmit]

Any advice?

[ybelMekk]

The user_info has no params, so no params is checked.

When a GET to user_info is requested, the mock-server just checks the Authorization header for Bearer , validates token and returns the claims as a json body.

[ybelMekk]

https://openid.net/specs/openid-connect-core-1_0.html#UserInfo

@gpsmit im not so familiar with spring and the ouath2 client, but can you intercept the Bearer token/request sent to the mock-oauth2-server?

[gpsmit]

@ybelMekk sorry was on vacation for two weeks.
Steps to reproduce can be done with mock-oauth2-server:2.0.0 docker and the above config
I would expect the email claim from the above config to be returned from /issuer1/userinfo:

1. Start docker and go to /issuer1/debugger
2. As scopes define openid email
3. Get token
4. Use token to perform call to /issuer1/userinfo with Authorization Bearer header
5. Check json result: does not contain email claim

[gpsmit]

Perhaps the above config is not appropriate for user info calls, then I would love to know how one would go about configuring mock values for the user info endpoint.
And, if not possible yet; consider this a feature request.

[ybelMekk]

@gpsmit
I'm going away for a couple of days. I'll get back to you once I've had the time to troubleshoot.

[ybelMekk]

@gpsmit, after conducting some tests and observations, I'd like to explain the following:

{
    "interactiveLogin": true,
    "httpServer": "NettyWrapper",
    "tokenCallbacks": [
        {
            "issuerId": "issuer1",
            "tokenExpiry": 120,
            "requestMappings": [
                {
                    "requestParam": "scope",
                    "match": "read",
                    "claims": {
                        "email": "[email protected]"
                    }
                }
            ]
        }
    ]
}

• The requestParam serves as the key for a specific request-callback that the mocked server searches for within its tokenCallbacks.requestMappings[].

• In your case, the value of the scope key in the /token request should match the "read" value. Alternatively, you could use "requestParam": "grant_type" with "match": "authorization_code" or any "requestParam": "grant_type" with "match": "*".

To demonstrate, consider the following curl command:

curl -k -v -X POST -H 'Content-type: application/x-www-form-urlencoded' \
-d "client_id=mytestclient&scope=read&grant_type=client_credentials  http://localhost:8080/issuer1/token

Executing this command should generate a token containing the custom claim "email": "[email protected]".

Following this, you can make a request to the info_endpoint using:

curl -H "Authorization: Bearer ey.."  http://localhost:8080/issuer1/userinfo

The response should resemble the following JSON:

{
  "sub" : "testuser1",
  "aud" : [ "read" ],
  "nbf" : 1696922793000,
  "azp" : "mytestclient",
  "iss" : "http://localhost:8080/issuer1",
  "exp" : 1696926393000,
  "iat" : 1696922793000,
  "email": "[email protected]"
  "jti" : "645ef42b-771c-4fa9-83cc-07d9e0943ea1",
  "tid" : "issuer1"
}

I hope this has provided some clarity.

[gpsmit]

Thanks for clarifying.
I can indeed make it work if I choose grant_type = authorization_code, so I have a way forward thanks for that.

Still some discussion:
In the debugger, and per standard, I cannot say scope=read only, as it always needs a openid value in the scope. I cannot get a token without it, so mimimum would be scope=openid+read.
If I then configure match="openid read" it does match.

I guess my confusion arose from the exact whole string match:
In the debugger it shows as grant_type=authorization_code&code=some-code&scope=openid+email
Yet, configuring either email or openid+email did not work.
The match field need to be spaced for matching to work: "openid email"

It would be nice to be able to partial match on the requestParams, as scope values are almost always multi value.
To me it feels more natural -> I have configuration for the scope email, here is the mapping. The rest I leave at the defaults.

So a working config for the issue I described above would be:

{
    "interactiveLogin": true,
    "httpServer": "NettyWrapper",
    "tokenCallbacks": [
        {
            "issuerId": "issuer1",
            "tokenExpiry": 120,
            "requestMappings": [
                {
                    "requestParam": "scope",
                    "match": "openid email",
                    "claims": {
                        "email": "[email protected]"
                    }
                }
            ]
        }
    ]
}

Anyway, thanks for working through this with me.
much appreciated

[ybelMekk]

This can be a nice little feature, I can look into it 👍🏾

[ybelMekk]

@gpsmit seems like @kvokacka answered your 🙏🏾 #578

[gpsmit]

thanks guys, amazing work.
Again thanks for working through this with me, happily applying this project everywhere we need oauth