Introspect fail when header goes as authorization Basic

[a-maggi]

Hi, when I use the Instronspect class to get the information of an access token, the library make the request with a header authorization as Basic instead of being "Bearer" and ends up giving error the request for this reason.

Can the class be improved, so that you can choose what type of authorization to send?

Now the request are like this:

 headers:
   { 'User-Agent': 'openid-client/2.4.5 (https://github.com/panva/node-openid-client)',
     Accept: 'application/json',
     Authorization: 'Basic {ENCODED CLIENT ID AND SECRET}' },

I'm need:

 headers:
   { 'User-Agent': 'openid-client/2.4.5 (https://github.com/panva/node-openid-client)',
     Accept: 'application/json',
     Authorization: 'Bearer {ACCESS TOKEN}' },

[panva]

Hi @amaggic,

The implementation is correct. During token introspection requests the introspected token is transmitted via body ‘token’ field and the client authenticates using any registered method - in your case client secret basic.

https://tools.ietf.org/html/rfc7662

Seems your OP does not implement introspection by the book.

[a-maggi]

Thanks @panva for the fast answer!

Then the problem is my OP not use a standard based in the book.

[telemmaite]

@panva what about this ? https://tools.ietf.org/html/rfc7662#page-4

To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] OR a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750].

Then we have two examples for both ways:

POST /introspect HTTP/1.1 Host: server.example.com Accept: application/json Content-Type: application/x-www-form-urlencoded Authorization: Bearer 23410913-abewfq.123483

 token=2YotnFZFEjr1zCsicMWpAA

OR

POST /introspect HTTP/1.1 Host: server.example.com Accept: application/json Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

 token=mF_9.B5f-4.1JqM&token_type_hint=access_token

[panva]

separate OAuth 2.0 access token such as the bearer token doesn't mean the token you're introspecting, which is what i assume the OP wants