Bearer token in authorization header vs query parameter - API Craft

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Bearer token in authorization header vs query parameter
Received-SPF: neutral (google.com: 209.85.214.178 is neither permitted nor denied by domain of g...@apigee.com) client-ip=209.85.214.178;
MIME-Version: 1.0
In-Reply-To: <b6d9e85b-71ac-4099-acb5-3d73a742b...@f9g2000pbq.googlegroups.com>
References: <6a0629d9-c861-45b8-9348-7980e09f3...@jx17g2000pbb.googlegroups.com>
	<3DD21B24855F4EE3B21C4FC0EC553...@gmail.com>
	<CAPQtApemkwKfL4ahOKw7F77Y-QYdj7t2Ga0Y8JZL3O+Q-wr...@mail.gmail.com>
	<51D30573C07F2D41A6DE9D263913295328404...@BY2PRD0310MB377.namprd03.prod.outlook.com>
	<b6d9e85b-71ac-4099-acb5-3d73a742b...@f9g2000pbq.googlegroups.com>
Date: Thu, 19 Apr 2012 13:01:08 -0700
Message-ID: <CALeNzwkLqeMZvm0=6tJXbUHo=MsH-J7E-g+9BG139D+PaKK...@mail.gmail.com>
Subject: Re: Bearer token in authorization header vs query parameter
From: Greg Brail <g...@apigee.com>
To: api-craft@googlegroups.com
Content-Type: multipart/alternative; boundary=e89a8f13ec6602429d04be0da260

--e89a8f13ec6602429d04be0da260
Content-Type: text/plain; charset=ISO-8859-1

FWIW the OAuth 2.0 bearer token spec says that servers MUST support the
Authorization header and MAY support the query param. That means that if
you support the query param, then you must support the header too. What to
do if you see both? Good question...

The spec also strongly discourages using the query param:

   Because of the security weaknesses associated with the URI method
   (see Section 5
<http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-18#section-5>),
including the high likelihood that the URL
   containing the access token will be logged, it SHOULD NOT be used
   unless it is impossible to transport the access token in the
   "Authorization" request header field or the HTTP request entity-body.
   Resource servers MAY support this method.


and again in the "security considerations" section at the end...


   Don't pass bearer tokens in page URLs:  Bearer tokens SHOULD NOT be
      passed in page URLs (for example as query string parameters).
      Instead, bearer tokens SHOULD be passed in HTTP message headers or
      message bodies for which confidentiality measures are taken.
      Browsers, web servers, and other software may not adequately
      secure URLs in the browser history, web server logs, and other
      data structures.  If bearer tokens are passed in page URLs,
      attackers might be able to steal them from the history data, logs,
      or other unsecured locations.



On Thu, Apr 19, 2012 at 10:39 AM, Matt <m...@implbits.com> wrote:

> Our discussions ended with the proposal that we support both...  since
> our audience may invoke from "client-side" javascript and also from
> "server-side" code (were the authorization header could be set).
> Remaining discussion item is....  If we support both, what do we do if
> some idiot API caller uses both.  Error?   Take the value of the to
> authorization header and ignore query string?  Take the value of the
> query string and ignore the authorization header?
>
> On Apr 19, 9:27 am, Arlo Belshee <Arlo.Bels...@microsoft.com> wrote:
> > We argue over this general problem a lot internally.
> >
> > Following the HTTP spec (and the good reasons behind that guidance),
> clearly the right place for this sort of thing is in the headers. Query
> string is for stuff related to the query. Stuff related to the transaction
> or the communication (such as auth) goes in headers.
> >
> > Only one problem: JSONP. Browsers' behavior for cross-site data access
> from JS means that people had to hack a solution. That hack has become the
> norm and is JSONP. But there's one thing the hack fundamentally cannot do:
> send a header.
> >
> > There are more advanced (read complicated) workarounds for the browsers'
> security "feature" and some of them allow headers. But many JS libraries
> don't support these methods.
> >
> > Thus, you are forced to choose between following the standard (put in
> headers) or doing what will work for everyone (put in query string or
> path). Some people go each way.
> >
> > Arlo
> >
>



-- 
Gregory Brail  |  Technology  |  Apigee

--e89a8f13ec6602429d04be0da260
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

FWIW the OAuth 2.0 bearer token spec says that servers MUST support the Aut=
horization header and MAY support the query param. That means that if you s=
upport the query param, then you must support the header too. What to do if=
 you see both? Good question...<div>
<br></div><div>The spec also strongly discourages using the query param:<br=
><div><br></div><div><pre class=3D"newpage" style=3D"font-size:1em;margin-t=
op:0px;margin-bottom:0px">   Because of the security weaknesses associated =
with the URI method
   (see <a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-18=
#section-5">Section 5</a>), including the high likelihood that the URL
   containing the access token will be logged, it SHOULD NOT be used
   unless it is impossible to transport the access token in the
   &quot;Authorization&quot; request header field or the HTTP request entit=
y-body.
   Resource servers MAY support this method.</pre><pre class=3D"newpage" st=
yle=3D"font-size:1em;margin-top:0px;margin-bottom:0px"><br></pre><pre class=
=3D"newpage" style=3D"font-size:1em;margin-top:0px;margin-bottom:0px"><font=
 face=3D"arial, helvetica, sans-serif">and again in the &quot;security cons=
iderations&quot; section at the end...</font></pre>
<pre class=3D"newpage" style=3D"font-size:1em;margin-top:0px;margin-bottom:=
0px"><br></pre><pre class=3D"newpage" style=3D"font-size:1em;margin-top:0px=
;margin-bottom:0px">   Don&#39;t pass bearer tokens in page URLs:  Bearer t=
okens SHOULD NOT be
      passed in page URLs (for example as query string parameters).
      Instead, bearer tokens SHOULD be passed in HTTP message headers or
      message bodies for which confidentiality measures are taken.
      Browsers, web servers, and other software may not adequately
      secure URLs in the browser history, web server logs, and other
      data structures.  If bearer tokens are passed in page URLs,
      attackers might be able to steal them from the history data, logs,
      or other unsecured locations.
</pre><div><br></div><br><div class=3D"gmail_quote">On Thu, Apr 19, 2012 at=
 10:39 AM, Matt <span dir=3D"ltr">&lt;<a href=3D"mailto:m...@implbits.com">=
m...@implbits.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Our discussions ended with the proposal that we support both... =A0since<br=
>
our audience may invoke from &quot;client-side&quot; javascript and also fr=
om<br>
&quot;server-side&quot; code (were the authorization header could be set).<=
br>
Remaining discussion item is.... =A0If we support both, what do we do if<br=
>
some idiot API caller uses both. =A0Error? =A0 Take the value of the to<br>
authorization header and ignore query string? =A0Take the value of the<br>
query string and ignore the authorization header?<br>
<br>
On Apr 19, 9:27=A0am, Arlo Belshee &lt;<a href=3D"mailto:Arlo.Bels...@micro=
soft.com">Arlo.Bels...@microsoft.com</a>&gt; wrote:<br>
&gt; We argue over this general problem a lot internally.<br>
&gt;<br>
&gt; Following the HTTP spec (and the good reasons behind that guidance), c=
learly the right place for this sort of thing is in the headers. Query stri=
ng is for stuff related to the query. Stuff related to the transaction or t=
he communication (such as auth) goes in headers.<br>

&gt;<br>
&gt; Only one problem: JSONP. Browsers&#39; behavior for cross-site data ac=
cess from JS means that people had to hack a solution. That hack has become=
 the norm and is JSONP. But there&#39;s one thing the hack fundamentally ca=
nnot do: send a header.<br>

&gt;<br>
&gt; There are more advanced (read complicated) workarounds for the browser=
s&#39; security &quot;feature&quot; and some of them allow headers. But man=
y JS libraries don&#39;t support these methods.<br>
&gt;<br>
&gt; Thus, you are forced to choose between following the standard (put in =
headers) or doing what will work for everyone (put in query string or path)=
. Some people go each way.<br>
&gt;<br>
&gt; Arlo<br>
&gt;<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Gregory Brai=
l =A0| =A0Technology =A0| =A0Apigee<br>
</div></div>

--e89a8f13ec6602429d04be0da260--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
