4 ms·

> Making an authenticated call is a piece of cake, you just add an hibp-api-key header as follows: > GET https://haveibeenpwned.com/api/v3/breachedaccount/test

> Making an authenticated call is a piece of cake, you just add an hibp-api-key header as follows: > GET https://haveibeenpwned.com/api/v3/breachedaccount/test@example.com https://haveibeenpwned.com/api/v3/breachedaccount/test@examp... > hibp-api-key: [your key] Wouldn't the standard Authorization: Bearer <key> header be more compliant?

pionar 7y ago
No, because it's not a bearer token. Edit for clarity: A bearer token [0] is a concept for OAuth. This is not OAuth. [0] https://tools.ietf.org/html/rfc6750#section-1.2 https://tools.ietf.org/html/rfc6750#section-1.2
- Androider 7y ago
  OAuth doesn't have a monopoly on bearer tokens. And it is literally the definition of a bearer token: you shall know the messenger who presents this token, a concept old as history itself.
  - y4mi 7y ago
    Should every OS which uses windows be able to call itself Windows, because windows are a quite old thing as well? Like it or not, there is an rfc for this and using it for anything else would be code smell at best
    - patmorgan23 7y ago
      > Should every OS which uses windows be able to call itself Windows, because windows are a quite old thing as well? > Like it or not, there is an rfc for this and using it for anything else would be code smell at best No but every OS that uses windows can call them windows....
      - y4mi 7y ago
        I guess they should be able to call them windows. Can you link to any tool which uses bearer tokens and doesn't grant them through oauth2? Or it's internal, please explain how the token is obtained. I haven't seen any to date but I guess I could be wrong
        X-Istence 7y ago
        Github will happily hand you an access token by visiting "https://github.com/settings/tokens" https://github.com/settings/tokens". These are bearer tokens, in that the bearer gets granted access by that token alone. You happen to send it along in a Basic authentication in HTTP instead of as an Authorization header, but it is a bearer token all the same. No OAuth2 flow required.
        X-Istence 7y ago
        Any service that uses API keys are basically handing out bearer tokens. Whoever holds that API key can make requests to the service, it grants you access.
        OJFord 7y ago
        > Can you link to any tool which uses bearer tokens and doesn't grant them through oauth2? Yes: https://www.pelion.com/docs/device-management/current/integrate-web-app/api-keys.html https://www.pelion.com/docs/device-management/current/integr... (I know I've seen and used many others, but Pelion comes first to mind because I used to work on it.)
        Androider 7y ago
        It's incredibly common. See Stripe for example https://stripe.com/docs/api/authentication https://stripe.com/docs/api/authentication Authorization: Bearer <API Key>.
- theandrewbailey 7y ago
  JWT uses Authorization: Bearer, too. https://jwt.io/introduction/ https://jwt.io/introduction/
floatingatoll 7y ago
See also elsethread about "not a token" — but, also: > There's a couple of these and they're largely due to me trying to make sure I get this feature out as early as possible and continue to run things on a shoestring cost wise Using the Authorization header can cause significant problems with both clients and servers, and also might unintentionally permit browsers to directly query the server if they can be convinced to provide a bearer token. Using a custom HTTP header sidesteps both client and server issues altogether and closes the door on browsers direct-querying the API, which could be considered a positive by the site operator.
- theandrewbailey 7y ago
  I'm not sure how browsers using the API would be a concern. Someone paid for the key, so it should be up to them to use it how they please (within rate limits).
  - floatingatoll 7y ago
    Allowing browsers to query directly would break the terms of engagement specified by the site operator, who specified that a proxy shall be used to concentrate end-user requests for a given paid key. That’s their right as service operator. I can construct plausible scenarios why this is a sensible choice, but the underlying point is that they clearly regardless made that choice after thinking it through.
    - akerl_ 7y ago
      That’s not a requirement specified anywhere. The “Protecting the API Key“ section talks about using a proxy specifically in the context of client-side applications (think of things like 1Password that integrate w/ HIBP), where embedding the API key into the app is obviously undesirable. In those cases, using a proxy allows managing the request volume and injecting the API key. That same section of the document describes other scenarios, like a hosted service or a CLI tool, that do not involve a proxy service.
      - 7y ago

pionar 7y ago

No, because it's not a bearer token. Edit for clarity: A bearer token [0] is a concept for OAuth. This is not OAuth. [0] https://tools.ietf.org/html/rfc6750#section-1.2 https://tools.ietf.org/html/rfc6750#section-1.2

Androider 7y ago
OAuth doesn't have a monopoly on bearer tokens. And it is literally the definition of a bearer token: you shall know the messenger who presents this token, a concept old as history itself.
- y4mi 7y ago
  Should every OS which uses windows be able to call itself Windows, because windows are a quite old thing as well? Like it or not, there is an rfc for this and using it for anything else would be code smell at best
  - patmorgan23 7y ago
    > Should every OS which uses windows be able to call itself Windows, because windows are a quite old thing as well? > Like it or not, there is an rfc for this and using it for anything else would be code smell at best No but every OS that uses windows can call them windows....
    - y4mi 7y ago
      I guess they should be able to call them windows. Can you link to any tool which uses bearer tokens and doesn't grant them through oauth2? Or it's internal, please explain how the token is obtained. I haven't seen any to date but I guess I could be wrong
      - X-Istence 7y ago
        Github will happily hand you an access token by visiting "https://github.com/settings/tokens" https://github.com/settings/tokens". These are bearer tokens, in that the bearer gets granted access by that token alone. You happen to send it along in a Basic authentication in HTTP instead of as an Authorization header, but it is a bearer token all the same. No OAuth2 flow required.
        X-Istence 7y ago
        Any service that uses API keys are basically handing out bearer tokens. Whoever holds that API key can make requests to the service, it grants you access.
      - OJFord 7y ago
        > Can you link to any tool which uses bearer tokens and doesn't grant them through oauth2? Yes: https://www.pelion.com/docs/device-management/current/integrate-web-app/api-keys.html https://www.pelion.com/docs/device-management/current/integr... (I know I've seen and used many others, but Pelion comes first to mind because I used to work on it.)
      - Androider 7y ago
        It's incredibly common. See Stripe for example https://stripe.com/docs/api/authentication https://stripe.com/docs/api/authentication Authorization: Bearer <API Key>.
theandrewbailey 7y ago
JWT uses Authorization: Bearer, too. https://jwt.io/introduction/ https://jwt.io/introduction/

floatingatoll 7y ago

See also elsethread about "not a token" — but, also: > There's a couple of these and they're largely due to me trying to make sure I get this feature out as early as possible and continue to run things on a shoestring cost wise Using the Authorization header can cause significant problems with both clients and servers, and also might unintentionally permit browsers to directly query the server if they can be convinced to provide a bearer token. Using a custom HTTP header sidesteps both client and server issues altogether and closes the door on browsers direct-querying the API, which could be considered a positive by the site operator.

theandrewbailey 7y ago
I'm not sure how browsers using the API would be a concern. Someone paid for the key, so it should be up to them to use it how they please (within rate limits).
- floatingatoll 7y ago
  Allowing browsers to query directly would break the terms of engagement specified by the site operator, who specified that a proxy shall be used to concentrate end-user requests for a given paid key. That’s their right as service operator. I can construct plausible scenarios why this is a sensible choice, but the underlying point is that they clearly regardless made that choice after thinking it through.
  - akerl_ 7y ago
    That’s not a requirement specified anywhere. The “Protecting the API Key“ section talks about using a proxy specifically in the context of client-side applications (think of things like 1Password that integrate w/ HIBP), where embedding the API key into the app is obviously undesirable. In those cases, using a proxy allows managing the request volume and injecting the API key. That same section of the document describes other scenarios, like a hosted service or a CLI tool, that do not involve a proxy service.
    - 7y ago