How to handle possibly non-conforming token_type?

[abhijit-hota]

Slack's token exchange endpoint sends back a response where the token_type can be bot.

Example response from above link

{
    "ok": true,
    "access_token": "xoxb-17653672481-19874698323-pdFZKVeTuE8sk7oOcBrzbqgy",
    "token_type": "bot",
    "scope": "commands,incoming-webhook",
    "bot_user_id": "U0KRQLJ9H",
    "app_id": "A0KRD7HC3",
    "team": {
        "name": "Slack Pickleball Team",
        "id": "T9TK3CUKW"
    },
    "enterprise": {
        "name": "slack-pickleball",
        "id": "E12345678"
    },
    "authed_user": {
        "id": "U1234",
        "scope": "chat:write",
        "access_token": "xoxp-1234",
        "token_type": "user"
    }
}

I'm using openid-client's client.authorizationCodeGrant. I see that the response from Slack is successful but an UnsupportedOperationError is thrown probably because of the following check:

oauth4webapi/src/index.ts

Lines 3472 to 3474 in 3371192

	if (json.token_type !== 'dpop' && json.token_type !== 'bearer') {
	throw new UnsupportedOperationError('unsupported `token_type` value', { cause: { body: json } })
	}

Currently, I'm working around this by doing this:

Workaround

import { z } from "zod";
import { ClientError } from "openid-client";

const slackAccessTokenResponseSchema = z.object({
	body: z
		.object({
			ok: z.boolean(),
			access_token: z.string(),
			token_type: z.literal("bot"),
			team: z.object({
				name: z.string(),
				id: z.string(),
			}),
		})
		.passthrough(),
});

const res = await client
    .authorizationCodeGrant(config, url, { expectedState })
    .catch((err) => {
        // Slack sends the token_type as "bot" instead of "bearer"
        // and that isn't OAuth compliant so this library throws an
        // unsupported operation error. so we manually parse the error.
        if (
            err instanceof ClientError &&
            err.cause instanceof Error &&
            err.cause.name === "UnsupportedOperationError" &&
            typeof err.cause.cause === "object"
        ) {
            const errBody =
                slackAccessTokenResponseSchema.safeParse(
                    err.cause.cause,
                );
            if (errBody.success && errBody.data.body.ok)
                return errBody.data.body;
        }
        throw new Error(
            "Failed to exchange code for token",
        );
    });

I've also checked ClientCredentialsGrant type but it doesn't work and Slack rejects it with invalid_grant error. Moreover, Slack itself suggests sending authorization_code in grant_type.

I've considered manually calling the API as well.

1. First of all, is this non-conforming in anyway? Do we need to check the token if they are bearer or dpop? I couldn't find anything in the spec (Section 7.1) but I might be looking at the wrong place.

2. If it is, then is this is the only way to handle non-conforming token_type? Can we introduce some config or custom token_type handler?

[panva]

I have prototyped a WIP branch for

• oauth4webapi - 94564c6
• openid-client - panva/openid-client@d9d50ea

Not necessarily because I want to acknowledge and support slacks' non-conforming and entirely proprietary values (they are meant to just respond with "bearer" as that's how they actually intend to use that token) but because at least in the case of processGenericTokenEndpointResponse (oauth4webapi) and genericGrantRequest (openid-client) when making OAuth 2.0 Token Exchange N_A is used as a valid registered token type ("N_A is used to indicate that an OAuth 2.0 token_type identifier is not applicable in that context")

[abhijit-hota]

I see that this was released in https://github.com/panva/oauth4webapi/releases/tag/v3.7.0

Will test it out and close this

[panva]

I didn't ping you here it doesn't solve for openid-client's use. On purpose. I wanted to solve N_A for openid-client's use of genericGrant with the token exchange grant. I'm not solving for slack's proprietary token types that end up being used as "bearer" anyway.