Align IPFS API with pinning service API

tommy123ng_infura · October 7, 2021, 5:46pm

github.com/ipfs/pinning-services-api-spec

Defining API access controls

opened 10:46PM - 29 Jun 20 UTC

closed 02:16PM - 16 Jul 20 UTC

P3 help wanted need/analysis need/community-input topic/authorization

### Known constraints - Pinning Service API client integration in go/js-ipfs …should be vendor-agnostic (the same struct should be used for storing API location and credentials across all pinning services, the same authorization flow should work no matter what is on the other end) - language used in WebUI and similar GUI apps should be easy to understand (eg. one input for "API endpoint", second for "Secret API key", or a single button "authorize this node" that opens authorization flow) ### Q: how specific should this spec be? [v0.0.1 explicitly mentions JWT](https://github.com/ipfs/pinning-services-api-spec/blob/4932e123c22dbac1d0fa9631a3bd1ee914399f57/ipfs-pinning-service.yaml#L20-L27), but some vendors may prefer to use something else (eg. a simple "SECRET API KEY" generated per "bucket" etc). Clients and user interfaces do not care about what is inside an opaque "api token" – they will simply store it in config during initial configuration and then send it as-is with each request. For those reasons we may simplify the spec to require an opaque string (in GUIs labeled as "API KEY") passed in HTTP header, leaving its details up to pinning services, especially if we may remove the need for copying api key / token and decide to do authorization at well-known URL at Pinning Service. ### Q: How should authorization flow look like? - **Off-band:** pinning service generates "token"/"api key" value which is then entered into relevant UIs by the user. It is up to Pinning Service to implement UI for creation and management of those tokens. All requests to the Pinning Service will include this static token. or - **Seamless:** Pinning service provides authorization endpoint that can be opened to add specific PeerID to allowlist. Then, use private libp2p-key for signing requests to the Pinning Service. ### Q: How should authorization token be passed with requests? Which way of passing authorization credentials makes sense? - [`Authorization: Bearer <token>`](https://swagger.io/docs/specification/authentication/bearer-authentication/) (could be JWT, or something else) - [`X-API-Key: <api-key>`](https://swagger.io/docs/specification/authentication/api-keys/) - something else? Looking for feedback.

IPFS community want to use HTTP Bearer for API auth.

Currently Infura IPFS use basic auth instead of Bearer so that it is not compatible with IPFS spec.

Please consider to contribute to discussion in github or implement HTTP Bearer for IPFS API auth.

lovekosmas · October 8, 2021, 4:03pm

Hi @tommy123ng_infura and welcome to the Infura community!

Thank you for sharing your request!
We are always interested in hearing how we can improve our product.

I have shared this information with the team.