Feature request: Token- or API-key–based auth for the DataCite REST API (in addition to Basic)

[davidelbert]

We use the DataCite REST API at https://api.datacite.org to mint DOIs and update metadata for our repository (PARADIM with prefix 10.34863). The API currently requires HTTP Basic auth with repository credentials for write operations. Please add support for token-based (e.g., OAuth2 access tokens or scoped Personal Access Tokens) and/or API-key authentication to improve security, auditability, and automation workflows.

Why this matters

• Least privilege: scoped credentials (e.g., read:metadata, write:metadata, mint:dois) reduce blast radius versus a shared repository password.
• Rotation and revocation: rotate/revoke a single token/key without impacting other integrations.
• Auditability: attribute changes to a specific token/key rather than a shared Basic credential.
• Precedent: DataCite already uses JWT tokens for the Usage Reports API; extending token auth to REST aligns with existing practice.

Proposed approach (backward-compatible)

• Support Bearer tokens via Authorization: Bearer (short-lived OAuth2 access tokens and/or long-lived but scoped PATs).
• Optionally support an API key header (e.g., X-API-Key: ), with per-key scopes and expiry.
• Optionally allow constraints on credentials (limit to specific client-id and/or prefix).
• Keep Basic auth working for ease of use or at least during transition (and document deprecation plan)

Example:

PUT /dois/10.1234/abcd
Authorization: Bearer eyJhbGciOi...
Content-Type: application/vnd.api+json

{ "data": { "type": "dois", "id": "10.1234/abcd",
  "attributes": { "contributors": [ ... ] } } }

Proposed acceptance criteria

• REST endpoints accept Bearer tokens and (optionally) API keys in addition to Basic.
• Tokens/keys can be issued with scopes and expiry; requests outside scope return 403.
• Tokens/keys can be revoked server-side; revoked credentials are rejected within a bounded time.
• Server logs/metrics capture a credential identifier to enable per-credential audit trails.
• Documentation updated: auth methods, scopes, example requests, and migration guidance.

Thanks!

[codycooperross]

Hi @davidelbert ! FYI, I converted your issue into a discussion. You can learn more about Suggestions discussion forum here.

Thank you for this very helpful proposal for enhancements to DataCite API authorization. We've noted on our Roadmap that we plan to focus on authorization soon, so we'll factor this thinking into our approach. We'll watch this thread for further discussion, so feel free to provide additional context and related suggestions here.

[davidelbert]

Thanks @codycooperross! I'm not sure how many people are using the API extensively or will find this to discuss, but I'll participate in anyway I can to help.

[codycooperross]

Hi @davidelbert ! I wanted to signal that we're working an API key implementation, described in broad strokes in this new discussion: #251 Your feedback here has helped us shape the feature set, so thank you again for contributing. We welcome any further considerations in the linked thread!

[codycooperross]

Hi @davidelbert , we recently released an API key implementation that adopts many of the features you describe above, including backwards compatibility with Basic authorization, revocation of single keys, and more. You can learn about the feature in our release notes and in our Support documentation. Let us know what you think, and thanks again for your feedback!