Hi, Olivier. Please check [this doc](https://gluu.org/docs/ce/3.1.4/operation/logs/) and make sure you set logging level to DEBUG for oxAuth, then re-try your flow and see whether there will be something in `oxauth.log` this time.

Hi Aliaksandr, Thanks for the doc. I tried raising OxAuth logs to "DEBUG" but I still don't see any trace of the failing UserInfo request. If I monitor Apache httpd access logs during my test, I see the following requests received: X.X.X.X - - [21/Jan/2019:11:22:42 +0000] "GET /oxauth/restv1/authorize?scope=openid+email+profile+permission&redirect_uri=...&client_id=...&response_type=code&state=... HTTP/1.1" 302 - "https://jupyter.biomass-maap.com/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0" Y.Y.Y.Y - - [21/Jan/2019:11:22:42 +0000] "POST /oxauth/restv1/token HTTP/1.1" 200 946 "-" "JupyterHub" Y.Y.Y.Y - - [21/Jan/2019:11:22:42 +0000] "GET /oxauth/restv1/userinfo HTTP/1.1" 401 349 "-" "JupyterHub" But, if I monitor OxAuth debug logs, the last trace I have is the end of successfully handling "token" request : 2019-01-21 11:22:42,394 DEBUG [qtp804611486-14] [xdi.oxauth.token.ws.rs.TokenRestWebServiceImpl] (TokenRestWebServiceImpl.java:168) - Issuing access token: 76d4571f-6058-4092-b8da-c792b239c854 2019-01-21 11:22:42,401 DEBUG [qtp804611486-14] [org.xdi.oxauth.model.common.AuthorizationGrant] (AuthorizationGrant.java:150) - Saving grant: d1220ed8-0ed0-4f48-896f-274c450f368b, code_challenge: null Do you have any idea of what might block UserInfo request with HTTP 401 error between Apache proxy and OxAuth application? Regards, Olivier

Hi again, Finally found out what was going on, I'll just trace it here in case in might help others: in fact, my client application (Jupyter) was sending its request to "UserInfo" endpoint with Authorization header containing "bearer <AccessTokenValue>"; the HTTP 401 error was caused by the case of "bearer" word, OxAuth expects uppercase first letter "Bearer" instead. For now, I did a workaround at Gluu's Apache configuration level using RequestHeader directive: RequestHeader edit Authorization bearer Bearer I hope it might help others that face the same issue... Regards, Olivier

Hi, Oliver. Thanks for letting us know. I've asked the developer responsible for this feature to have a look at it, as it seems a bit strange.

According to the developer, it already works as [this spec](https://tools.ietf.org/html/rfc6750#section-2.1) requires: ``` b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" credentials = "Bearer" 1*SP b64token ``` "B" must be in the upper case.

I have the same error. I try to authenticate with Gluu Server 4.1.0 (running on Debian 10), from a Node application using passeport.js and [node-openid-client](https://github.com/panva/node-openid-client). My applications works fine with other OP, but it refuses to authenticate with Gluu Server. The error is caused by the `token_type` field returned by Gluu "/token" endpoint : this token_type is set to `bearer`, thus the following request to "/userinfo" endpoint does not recognize the Authorization header, because its value is `Authorization: bearer xxxxxxxx`. If I hardcode the token_type to "Bearer" in the node-openid-client library, I can authenticate with my Gluu Server. In the RFC 6750,[ the token_type value is described as "Bearer"](https://tools.ietf.org/html/rfc6750#page-14), with an uppercase "B". So should I consider this as a bug in Gluu "/token" endpoint ? I think it is strange that so few people encounter this problem. Maybe I am missing something ?