Closed dogeared closed 6 years ago
Hmm.. the res.user
is the response from the Userinfo endpoint. I'm thinking why doesn't your ID Token have the subject field (sub).
We could use id_token as a fallback, if the user is not set.
the id_token does have a sub
claim.
It looks like the call to /userinfo
is failing. Here's what I have in the error.log:
2017/08/24 20:31:07 [error] 6966#0: *9869 [lua] openidc.lua:270: openidc_call_userinfo_endpoint(): accessing userinfo endpoint (https://micah.oktapreview.com/oauth2/aus9vmork8ww5twZg0h7/v1/userinfo) failed: 20: unable to get local issuer certificate, client: 127.0.0.1, server: kong, request: "GET /example/?code=ABsh65c44uqPQcnh_Bdq&state=70e6d54f00eb86dee7985413f6c08156 HTTP/1.1", host: "localhost:8000"
It should be using the access_token
(which it has) as a bearer token to hit the /userinfo
endpoint.
If I do it from the command line (using httpie) with the access_token, I get a response:
http \
https://micah.oktapreview.com/oauth2/aus9vmork8ww5twZg0h7/v1/userinfo \
Authorization:"Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ik93bFNJS3p3Mmt1Wk8zSmpnMW5Dc2RNelJhOEV1elY5emgyREl6X3RVRUkifQ..."
here's the response:
{
"email": "micah+okta@afitnerd.com",
"email_verified": true,
"family_name": "Silverman",
"given_name": "Micah",
"locale": "en-US",
"name": "Micah Silverman",
"preferred_username": "micah+okta@afitnerd.com",
"sub": "00u9vme99nxudvxZA0h7",
"updated_at": 1490198843,
"zoneinfo": "America/Los_Angeles"
}
My guess is that X-Userinfo
is only to be set when a call to the userinfo endpoint is made and succeeds. If so, I'd use if res.user then
as the condition. In your case the call fails because of a certificate verification issue which probably means that you need to set lua_ssl_trusted_certificate
.
FIxed in version 1.0.3.
In a typical flow, the response coming back from the OIDC
OP
has anid_token
and anaccess_token
(depending on theresponse_type
used to setup the flow).Here's a real world response returned form
kong-oidc
after interacting with Okta's OIDC service (header and signature removed from the access token. You can still inspect the payload):After authenticating, Kong is throwing an error:
Looking at the error log, I see:
Looking at
handler.lua
, I see:Why is it looking for
res.user
in the response?If I change these two lines to use:
res.id_token
instead, then everything works.