OpenIDC / liboauth2

OAuth 2.x and OpenID Connect C library
Apache License 2.0
105 stars 26 forks source link

Option for setting the token_type_hint #39

Closed bartjanssens92 closed 2 years ago

bartjanssens92 commented 2 years ago

Hallo,

When trying to switch from the OIDC module to the Oauth2 one we noticed that the post to the introspection endpoint included a new parameter in the data, token_type_hint, for example:

[auth_openidc:debug] [pid 2770419] src/util.c(689): [client 192.168.151.125:60374] oidc_util_http_call: url=https://endpoint.xx/oauth2/introspect, data=token=5bc8e5a9-8110-3c50-8559-b2f1852bd815, content_type=application/x-www-form-urlencoded, basic_auth=name:pass, bearer_token=(null), ssl_validate_server=1, timeout=60, outgoing_proxy=(null), pass_cookies=0, ssl_cert=(null), ssl_key=(null)
vs
[oauth2:debug] [pid 2770067] src/http.c(979): [client 192.168.151.60:49988] oauth2_http_call: enter: url=https://endpoint.xx/oauth2/introspect, data=token=5bc8e5a9-8110-3c50-8559-b2f1852bd815&token_type_hint=access_token, ctx=[ ssl_verify=true basic_auth_username=name basic_auth_password=password hdr=[ Content-Type=application/x-www-form-urlencoded ] cookie=[ ] ]

Looking at the token this type is set wrong and thus denies access. When recreating the post request with curl but changing this to bearer solves the issue:

curl -XPOST -u 'name:password' -H 'content_type: application/x-www-form-urlencoded' https://endpoint.xx/oauth2/introspect -d 'token=5bc8e5a9-8110-3c50-8559-b2f1852bd815&token_type_hint=bearer'
{"scope":"openid","active":true,"token_type":...

When rebuilding the liboauth2 with the value for OAUTH2_INTROSPECT_TOKEN_TYPE_HINT_ACCESS_TOKEN set to bearer it also fixes our issue. Is there a way to configure the value for this without having to change it in code, if not, are there any plans to make this possible?

zandbelt commented 2 years ago

access_token is actually the correct value for an access token; rfc7662 points to rfc7009 for the registered values of token_type_hint which include access_token and refresh_token, not bearer; I wonder what, apparently non-compliant, implementation you're introspecting against?

bartjanssens92 commented 2 years ago

The party we are trying to integrate with uses the WSO2 identity provider: https://is.docs.wso2.com/en/latest/. My guess is that WSO2 is not strictly following the RFC?

zandbelt commented 2 years ago

perhaps a version problem then because https://is.docs.wso2.com/en/latest/guides/access-delegation/invoke-oauth-introspection-endpoint/ shows that access_token is correct and accepted

zandbelt commented 2 years ago

some searching reveals that WSO2 changes this between 5.8.0 and 5.9.0; 5.8.0 is deprecated anyway, see https://wso2.com/products/support-matrix/

bartjanssens92 commented 2 years ago

Seems to be a version change mismatch indeed, the equivalent page https://docs.wso2.com/display/IS560/Invoke+the+OAuth+Introspection+Endpoint of their version lists You can pass the token type as an optional parameter in the request (e.g., token_type_hint=bearer ). I'll ask if there's a plan to upgrade to a newer version that does use access_token.

bartjanssens92 commented 2 years ago

In the meantime we'll switch back to using the OIDC module, thank you for your help!