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

API Keys

Expand Messages
  • Erlend Hamnaberg
    Hi. Is there anyone with experiences with implementing API Keys in their apis? Putting the APIKey in the URI is obviously a bad idea as that leaks to every
    Message 1 of 7 , Nov 29, 2012
    • 0 Attachment
      Hi.

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

      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.
    • Will Hartung
      Go look at Amazon Web Servuces and how they do this. They address thus and it s well documented and there are client and even some server side open codes you
      Message 2 of 7 , Nov 29, 2012
      • 0 Attachment
        Go look at Amazon Web Servuces and how they  do this. They address thus and it's well documented and there are client and even some server side open codes you can use. 

        AWS does most everything folks want and they've put some thought into it. 

        On Thursday, November 29, 2012, Erlend Hamnaberg wrote:
         

        Hi.


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

        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.


        CONFIDENTIALITY NOTICE: The information contained in this electronic transmission may be confidential. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by email reply and then erase it from your computer system.
      • Cíat Ó Gáibhtheacháin
        ... The WWW-Authenticate and Authorization headers exist for this very purpose. In fact, RFC 2617 is designed to be extensible. ... HTTP auth headers. There s
        Message 3 of 7 , Nov 29, 2012
        • 0 Attachment
          On Thu, Nov 29, 2012 at 12:26:00PM +0100, Erlend Hamnaberg wrote:

          > Is there anyone with experiences with implementing API Keys in their apis?
          >
          > 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 WWW-Authenticate and Authorization headers exist for this very
          purpose. In fact, RFC 2617 is designed to be extensible.

          > 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?

          HTTP auth headers. There's really no need for anything else except maybe
          in cases where it's not possible to use HTTP auth (such as embedding a
          fragment of JavaScript in a page, such as with Google Analytics, in
          which case you're not going to care much about spoofability anyway). For
          all other cases, using the existing HTTP auth headers is the right way
          to go because you *are* performing a form of auth with an API key.

          > ps:
          > I am thinking about writing up an internet draft for a new Api-Key header
          > field.

          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

          Of course, that assumes a fixed key. If you wanted something more secure
          and less liable to be spoofed, 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

          K.

          --
          Cíat Ó Gáibhtheacháin - k@... - http://stereochro.me/ - CF9F6473
          True happiness comes from the joy of deeds well done,
          the zest of creating things new.
          -- Antoine de Saint-Exupery
        • 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 4 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 5 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 6 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 7 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.