Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] API Keys

Expand Messages
  • C�at � G�ibhtheach�in
    ... This isn t the case, otherwise the likes of OAuth (which I mention later) wouldn t be possible. ... I think you might be missing the greater point I was
    Message 1 of 7 , Nov 29, 2012
    • 0 Attachment
      On Thu, Nov 29, 2012 at 02:16:50PM +0100, Erlend Hamnaberg wrote:

      > This seems to indicate that a User and Acces to the API is the same.
      > It is not in this case.

      This isn't the case, otherwise the likes of OAuth (which I mention
      later) wouldn't be possible.

      > Using Authorization was considered, but we need to use this for user
      > authentication. API authorization is a different step.
      >
      > AFAIK you MAY NOT send multiple challenges back to the server.

      I think you might be missing the greater point I was trying to make,
      which were that an existing mechanism already exist (RFC 2617):

      > The WWW-Authenticate and Authorization headers exist for this very
      > purpose. In fact, RFC 2617 is designed to be extensible.

      In fact, is this very extensibility that OAuth is built upon. OAuth
      might not be ideal for your particular purpose, but RFC 2617 still
      exists to build upon to quite possibly do what you want.

      It's possible to build an RFC 2617 auth method that could potentially
      bundle multiple challenges in a single aggregate challenge. Including
      multiple 'WWW-Authenticate' and 'Authorization' headers is another
      matter, however.

      Without knowing more about how your system's access management
      requirements, it's hard to speculate further. I think it would be more
      valuable to propose an auth method built on top of RFC 2617 to support
      your requirements rather than a whole new header.

      --
      C�at � G�ibhtheach�in - k@... - http://stereochro.me/ - CF9F6473
      There are 10^11 stars in the galaxy. That used to be a huge number. But it's
      only a hundred billion. It's less than the national deficit! We used to call
      them astronomical numbers. Now we should call them economical numbers.
      -- Richard Feynman
    • Jan Algermissen
      Hi Erlend, ... If you are looking for something along the lines of OAuth Client identifiers, you should take a look at OAuth 1 and 2 and the associated
      Message 2 of 7 , Nov 29, 2012
      • 0 Attachment
        Hi Erlend,

        On Nov 29, 2012, at 12:26 PM, Erlend Hamnaberg <ngarthl@...> wrote:

        > Hi.
        >
        >
        > Is there anyone with experiences with implementing API Keys in their apis?

        If you are looking for something along the lines of OAuth Client identifiers, you should take a look at OAuth 1 and 2 and the associated discussions.

        Eran IMO is the go-to guy in that space and you should get much out of his blog

        http://hueniverse.com

        and recent projects

        https://github.com/hueniverse/oz

        https://github.com/hueniverse/hawk (The README should provide a very good start).

        Looking at Amazon IAM, as already suggested, is also good:

        http://aws.amazon.com/documentation/iam/

        Here are good intro docs from Google:

        https://developers.google.com/accounts/docs/OAuth2

        Personally, I am most excited about OZ, because Eran's OAuth 2 criticism looks very valid when you dig into it.


        HTH
        Jan


        >
        > Putting the APIKey in the URI is obviously a bad idea as that leaks to every cache and intermediary. Including Apache logs.
        >
        > So it must be a new header field.
        >
        > The problem with APIKeys as such is that they are spoofable, unless they are crypographically protected somehow, so my question is:
        >
        > What do you do in your api?
        >
        >
        > --
        > Erlend
        >
        >
        > ps:
        > I am thinking about writing up an internet draft for a new Api-Key header field.
        >
        >
      • Nicholas Shanks
        ... And here s another: http://tools.ietf.org/html/draft-shanks-http-form-authentication-00 My first I-D, posted this week. :) — Nicholas. On 29 Nov 2012, at
        Message 3 of 7 , Nov 29, 2012
        • 0 Attachment
          On 29 Nov 2012, at 12:55, Cíat Ó Gáibhtheacháin <k@...> wrote:

          you'd end up with something similar to
          Digest auth, so you might want to consider just using that unless you
          can come up with something provably superior. Here's an example of an
          alternative auth method:

             http://www.xml.com/pub/a/2003/12/17/dive.html

          And here's another:
          http://tools.ietf.org/html/draft-shanks-http-form-authentication-00
          My first I-D, posted this week. :)

          — Nicholas.
        • Peter Williams
          ... +1, HTTP auth is a tragically underused part of the standard. Peter barelyenough.org
          Message 4 of 7 , Nov 29, 2012
          • 0 Attachment
            On Thu, Nov 29, 2012 at 5:55 AM, Cíat Ó Gáibhtheacháin <k@...> wrote:
            > You'd be better off proposing an alternative HTTP auth method, if
            > anything, where the client sends something like this (assuming the API
            > key is a UUID):
            >
            > Authorization: Key b67570be-3a22-11e2-8ca6-0015c55d83ee

            +1, HTTP auth is a tragically underused part of the standard.

            Peter
            barelyenough.org
          Your message has been successfully submitted and would be delivered to recipients shortly.