GitHub

GitHub clients are plain OAuth2 — no OIDC. They never issue an id_token, even when the scope includes openid — exactly like the real provider, which does not implement OIDC. An OIDC library pointed at a GitHub-type client will find no ID token to validate, the same as in production; an app integrating GitHub must fetch the profile endpoints below with the access token.

Token response quirks

• token_type is "bearer" (lowercase) — as real GitHub returns it. Token-type comparisons in your app should be case-insensitive per RFC 6750; if yours isn’t, you’ll hit it here first rather than in production.
• expires_in is omitted entirely — mirroring GitHub app tokens, which do not expire. Don’t assume the field is present when parsing the response.

The code is exchanged with a form-encoded POST to the token endpoint.

Fetching the user profile

GitHub clients expose the real provider’s profile API, so your app’s provider adapter works unmodified — GET /user and GET /user/emails with the access token as a Bearer token, returning GitHub-shaped JSON:

GET https://minutemail.co/idp/user
Authorization: Bearer at_EXAMPLEACCESSTOKEN

{
  "id": "ident_01JEXAMPLE",
  "login": "tricia",
  "name": "Tricia McMillan",
  "email": "tricia@minutemail.cc",
  "avatar_url": "https://example.com/avatar.png"
}

GET https://minutemail.co/idp/user/emails
Authorization: Bearer at_EXAMPLEACCESSTOKEN

[
  {
    "email": "tricia@minutemail.cc",
    "primary": true,
    "verified": true
  }
]

verified in the emails array reflects the identity’s emailVerified field, so you can test both branches of your email-verification logic on GitHub-type clients too.

PKCE

GitHub clients ignore PKCE parameters, mirroring the real GitHub web application flow, which has no PKCE. Sending code_challenge to those clients is harmless — it is simply not enforced.