Bitly Authentication

generated: '2026-08-13'
method: searched
source: >-
  https://dev.bitly.com/docs/getting-started/authentication (docs), enriched over the derived
  baseline from openapi/_original/bitly-v4-openapi.json and the live RFC 8414 metadata at
  https://api-ssl.bitly.com/.well-known/oauth-authorization-server
docs: https://dev.bitly.com/docs/getting-started/authentication
summary:
  types: [http, oauth2]
  primary: bearer token
  scopes_published: false
  note: >-
    Bitly's OpenAPI declares only a single `bearerAuth` HTTP bearer scheme. That understates the
    real posture: Bitly also runs a full OAuth 2.0 authorization server, discoverable at
    /.well-known/oauth-authorization-server on the API host, which is what the MCP server
    authenticates against. The spec never models it, so a spec-only read of Bitly's auth is
    wrong. No scopes are defined anywhere — tokens carry the full permissions of the granting
    user and group.
schemes:
- name: bearerAuth
  type: http
  scheme: bearer
  in: header
  header: Authorization
  format: 'Authorization: Bearer {token}'
  description: >-
    A generic access token generated from Bitly account Developer settings. This is the path
    Bitly's docs recommend for point-to-point integrations and is what the MCP quickstart uses.
  token_source: https://bitly.com/settings/api
  sources: [openapi/_original/bitly-v4-openapi.json]
- name: oauth2
  type: oauth2
  description: >-
    Used to act on behalf of an end user so that shortened links land in that user's own Bitly
    history. Not declared in Bitly's OpenAPI; documented in the auth guide and advertised in
    RFC 8414 metadata on the API host.
  issuer: https://bitly.com
  flows:
    authorizationCode:
      authorizationUrl: https://bitly.com/oauth/authorize
      tokenUrl: https://api-ssl.bitly.com/oauth/access_token
      scopes: {}
  registration_endpoint: https://api-ssl.bitly.com/oauth/register
  jwks_uri: https://api-ssl.bitly.com/.well-known/jwks.json
  grant_types_supported: [authorization_code]
  response_types_supported: [code]
  code_challenge_methods_supported: [S256]
  token_endpoint_auth_methods_supported: [client_secret_post, client_secret_basic, none]
  id_token_signing_alg_values_supported: [RS256]
  dynamic_client_registration: true
  app_registration: >-
    Log in to Bitly, open Developer settings and click "Register new app"; a client_id and
    client_secret are issued after email confirmation.
  sources:
  - https://dev.bitly.com/docs/getting-started/authentication
  - well-known/bitly-oauth-authorization-server.json
legacy_flows:
- name: Resource Owner Credentials Grant
  status: documented
  note: >-
    POST username+password to /oauth/access_token with HTTP Basic credentials. Bitly still
    documents it; it is a deprecated pattern in OAuth 2.1 and should not be used for new work.
- name: HTTP Basic Authentication
  status: documented
  note: >-
    Single-call token retrieval intended for command-line scripts. Accounts with two-factor
    authentication cannot use it — Bitly returns `2FA_CODE_REQUESTED` and requires a second
    request carrying an SMS code.