startsWith('Bearer ')) { const token = authHeader.split(' ')[1]On Sun, Jul 6, 2025 at 2:27 PM John Kemp <stable.pseudo...@gmail.com> wrote:Hi Dick,
El 07/06/25 a las 08:22, Dick Hardt escribió:
> Hey
>
> I was working with Claude on an MCP server which requir
Hi Dick,
El 07/06/25 a las 08:22, Dick Hardt escribió:
Hey
I was working with Claude on an MCP server which requires
authorization, and it generated this code, const authHeader =
request.headers.authorization if (authHeader &&
authHeader.startsWith('Bearer ')) { const token = authHeader.split('
So the token does need a key to be used at the RS, and it’s the
second part of the client that holds the key.
Yup. Makes sense to me.
- johnk
— Justin
On Jun 7, 2025, at 9:51 AM, John Kemp
wrote:
Some initial feedback upon a quick read (with no background
context for this issue):
[..
Some initial feedback upon a quick read (with no background context for
this issue):
[...]
that up again and see if that interim can get scheduled soon. I’d
also like to encourage people to read through the draft and open the
discussion here on the list more.
* What is the point of using the
There is AFAIK still no limit specified in HTTP itself on the maximum
header length, but individual servers (e.g. nginx) usually set their own
server-specific limits (8k seems common, and is what nginx does):
http://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers
T
I just wanted to make people on this thread aware of the related IETF
WIMSE (https://datatracker.ietf.org/group/wimse/about/) work, as well as
note SPIFFE issue #315 (https://github.com/spiffe/spiffe/issues/315) as
being pieces of related work to profile JWTs to work with SPIFFE/SPIRE.
Regards
Monday is also Columbus Day in the US, and thus many people there are
also off work on that day.
Regards,
- johnk
On 10/02/2014 12:44 PM, Phil Hunt wrote:
Monday is Canadian Thanksgiving holiday. Apologies if I marked that as yes in
the survey.
I will try to attend monday anyway if thursday
ing the user from phishing, you may not be as reliant on a client secret
as if the content may be accessed only by authorized software installations in
addition to authorized users.
- John
>
> thanks
>
> paul
>
> On 12/19/11 1:21 PM, John Kemp wrote:
>> Hi Paul,
Hi Paul,
On Dec 19, 2011, at 12:50 PM, Paul Madsen wrote:
> Hi Mike, to some extent I think my question is not about specific security
> characteristics, but rather whether its realistic for our group to mandate
> that both server & native clients have the *same* security characteristics -
> p
Hi Paul,
On Dec 19, 2011, at 12:50 PM, Paul Madsen wrote:
> Hi Mike, to some extent I think my question is not about specific security
> characteristics, but rather whether its realistic for our group to mandate
> that both server & native clients have the *same* security characteristics -
> p
On Oct 4, 2011, at 2:38 PM, Marius Scurtescu wrote:
> On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones
> wrote:
> Existing practice is that simple ASCII strings like “email” “profile”,
> “openid”, etc. are used as scope elements. Requiring them to be URIs would
> break most existing practice.
>
>
Mike,
On Sep 7, 2011, at 1:26 PM, Michael Thomas wrote:
> On 09/07/2011 10:17 AM, Igor Faynberg wrote:
>> +300 (if I can do that) to indicate my strong agreement. But if somehow it
>> is decided to add a few sentences on saying that OAuth cannot deal with
>> key-logging, I will insist on addin
On Sep 6, 2011, at 4:36 PM, Michael Thomas wrote:
[…]
> But even if you did it once, how did you know that you didn't reveal your
> credentials
> to a bad guy?
>
> And I'm being told that this isn't even worthy of any mention anywhere? I came
> here hoping to hear that the attack wasn't possib
On Sep 6, 2011, at 4:10 PM, Michael Thomas wrote:
> John Kemp wrote:
>> On Sep 6, 2011, at 3:49 PM, Michael Thomas wrote:
>>> Except in the desktop web world, I choose from a *tiny* set of browsers:
>>> chrome, firefox, opera, and, uh, ie. To a lesser or greater exte
On Sep 6, 2011, at 3:49 PM, Michael Thomas wrote:
>
> Except in the desktop web world, I choose from a *tiny* set of browsers:
> chrome, firefox, opera, and, uh, ie. To a lesser or greater extent, I don't
> expect that the browsers themselves are malicious. Which is a pretty ok
> assumption.
It i
Michael,
On Sep 6, 2011, at 1:40 PM, Michael Thomas wrote:
> Hi all,
>
> Barry suggested that I might subscribe and explain what I sent him.
>
> My basic problem is that in neither the protocol nor the threats drafts,
> I can't seem to find what problem is actually trying to be solved with
> oa
On Aug 15, 2011, at 11:07 AM, Eran Hammer-Lahav wrote:
> (please don't use my sled.com work email address)
>
> I'll ask the chairs to open an issue for this.
>
> My proposed requires CSRF protected without adding additional requirements,
> and therefore, is within the scope of my editorial disc
On Aug 14, 2011, at 1:55 AM, Phillip Hunt wrote:
> No. I don't think so. In the new variant the client has to check the returned
> state to confirm it has not changed or associated with a different user.
>
> Previously the authz server had to do the checks.
In a CSRF attack, either of the tw
Hi Tony (et al),
On Aug 12, 2011, at 3:06 PM, Anthony Nadalin wrote:
[…]
> 2.Gene opens the spam mail and clicks on the link.
> 3.The server running Basil's website initiates an authorization
> request to Live. The request uses Plaxo's redirection URI.
And why does Live
g the ability to name the parameters of the
Bearer mechanism might become more interesting.
- John
> I don't think we should be associating the term 'access_token' with the
> bearer security mechanism.
>
> Thanks,
> George
>
> On 6/10/11 8:35 AM, John Kemp wrote
What does this mean for the HTTP Authorization header naming scheme for bearer
tokens?
As I understand this decision, we are discussing whether to standardize on the
name "access_token" when a bearer token is sent as either a URL query
parameter, or in a form POSTed body?
Currently the HTTP A
On May 24, 2011, at 4:04 PM, Mike Jones wrote:
> George, you are correct that resources and clients must agree upon the format
> of the bearer token to achieve interoperability. The means for achieving
> this agreement is out of the scope of this document.
I thought the means for achieving IOP
Forgot to reply to all...
-- Forwarded message --
From: John Kemp
Date: Wed, Nov 24, 2010 at 11:22 AM
Subject: Re: [OAUTH-WG] Dropping 'realm' parameter
To: Eran Hammer-Lahav
Hi Eran,
On Wed, Nov 24, 2010 at 2:57 AM, Eran Hammer-Lahav wrote:
> Over the pas
ation I would guess.
- johnk
>
>
>
>> - johnk
>>
>> On Aug 3, 2010, at 1:39 PM, Eran Hammer-Lahav wrote:
>>
>>> Fragments are perfectly valid in the Location header URI:
>>>
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-
.
Regards,
- johnk
On Aug 3, 2010, at 1:39 PM, Eran Hammer-Lahav wrote:
> Fragments are perfectly valid in the Location header URI:
>
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4
>
> EHL
>
>> -Original Message-
>> From: oaut
On Aug 2, 2010, at 11:31 PM, Brian Eaton wrote:
> On Mon, Aug 2, 2010 at 6:15 PM, David Stanek wrote:
> I just verified that the Python urllib client does send the fragment to the
> server. I've created a patch and will be created a bug on the Python tracker.
>
> Cool, but this doesn't seem rel
n
accessing the resource, and (thought it) knew what to do with the OAuth
mechanism.
- johnk
>
>
> On Thu, Jul 15, 2010 at 11:33 AM, John Kemp wrote:
> On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
>
> > I would like people to raise their hand and explain how this w
On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
> I would like people to raise their hand and explain how this will break
> actual 1.0 deployments.
What happens if a 1.0 client receives a WWW-Authenticate header from a 2.0
protected resource with the 'OAuth' mechanism specified? Might it
On Jul 13, 2010, at 4:06 PM, Blaine Cook wrote:
> On 13 July 2010 20:31, John Kemp wrote:
>> Where is that specified? Is that required for all implementations?
>
> It's not specified - I was referring to your earlier comments:
>
>> In the "bearer token"
On Jul 13, 2010, at 3:03 PM, Blaine Cook wrote:
> +1 on "like a password", or something similar-and-meaningful because
> that's exactly how it's being used here. Pre-shared key, shared
> secret, etc, would be fine. Keep in mind that authentication *will be
> done* using the bearer token, and the b
On Jul 13, 2010, at 2:46 PM, Richer, Justin P. wrote:
>>> I would be very unhappy if we equated access tokens with passwords.
>>>
>>> I agree with Dirk that "capability" is a more expressive phrase than either
>>> "shared secret" or "password".
>
>> Expressive to you and people well-versed in se
Hi Eran,
On Jul 13, 2010, at 1:40 PM, Eran Hammer-Lahav wrote:
>
> On 7/13/10 10:25 AM, "John Kemp" wrote:
>
>> On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
>>
>>> I am ok replacing it with Oacts as a password¹.
>>
>> An ac
On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
> I am ok replacing it with ‘acts as a password’.
An access token is something used by the server to decide whether a request is
authorized. Although it may also be used for authenticating the request(er),
it's purpose is to authorize the r
On Jun 7, 2010, at 8:25 PM, Manger, James H wrote:
> John,
>
>>> access_token=saml.fhHFhgf6575fhgFGrytr
>
>> What is the advantage of doing it this way over having a separate field?
>
> Client simplicity (code and mental model).
I think the difference in simplicity between one parameter and t
On Jun 6, 2010, at 11:14 PM, Manger, James H wrote:
> OAuth2 has a field for AS-to-PR communications via (but opaque to) the
> client: access_token. Any format indication (like a variety of other details)
> that an AS wants to convey to the PR via the client app should be *inside*
> this existi
Torsten,
On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote:
>
> Am 04.06.2010 19:45, schrieb John Kemp:
>> On Jun 4, 2010, at 1:35 PM, David Recordon wrote:
>>
>>
>>> #4 should happen as part of #3.
>>>
>> How would ALL OAuth 2.0
On Jun 4, 2010, at 1:35 PM, David Recordon wrote:
> #4 should happen as part of #3.
How would ALL OAuth 2.0+ clients know to pass along the format if it is there?
I fail to see the problem with specifying an optional token format parameter in
the main spec. and giving it a default value, and se
Hi Luke,
On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote:
>
> On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:
>
>> On 6/4/10 9:53 AM, Luke Shepard wrote:
>>>
>>> Having a single resource server that works with multiple independent auth
>>> servers is not in scope for OAuth. That said, ther
On Apr 22, 2010, at 2:21 PM, Brian Eaton wrote:
> On Thu, Apr 22, 2010 at 11:01 AM, Eran Hammer-Lahav
> wrote:
>> Rules around realms show this is very tricky but unless we update 2617
>> (which we
>> are not chartered to do) we are still stuck with realm as a required
>> parameter.
>> One way
Hi Brian,
On Apr 22, 2010, at 1:36 PM, Brian Eaton wrote:
> On Mon, Apr 19, 2010 at 3:17 PM, Eran Hammer-Lahav
> wrote:
>>> The scope doesn't have to match the base URI of the resource which the
>>> client tried and got the 401 from?
>>
>> That's a security issue we need to address (when to tr
You all might want to take a look at Thomas Broyer's cookie-auth HTTP auth
scheme: http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00 for what he
did to implement something reasonably similar.
I do think it would be nice if we don't abuse HTTP, which suggests we should
define a new HTT
On Apr 20, 2010, at 12:46 AM, Peter Saint-Andre wrote:
> On 4/18/10 6:46 PM, Dick Hardt wrote:
>
>> Given the practice that the authorization endpoint and the redirect_uri
>> can contain URI query parameters, then differentiating between
>> application specific query parameters and OAuth protocol
On Apr 19, 2010, at 6:17 PM, Eran Hammer-Lahav wrote:
[...]
>>>
>>
>> I think that there is much that is unspecified in this model and thus it
>> doesn't
>> provide much interoperability. If we don't tell the client what to do with
>> the
>> scope, and we don't specify what a server means by
On Apr 19, 2010, at 12:25 PM, Eran Hammer-Lahav wrote:
> Proposal:
>
> 'scope' is defined as a comma-separated list of resource URIs or resource
> groups (e.g. contacts, photos).
So, 'scope' at the authenticating (via OAuth) server is simply a list of one or
more URIs? There are no defined, int
On Apr 15, 2010, at 9:22 PM, Manger, James H wrote:
> I strongly favour specifying 2 separate endpoints: one for where to redirect
> a user, another for direct client calls.
I agree.
>
> I agree with Marius that these two endpoints are different enough to be
> separate.
> One is only used by
e a shorter
prefix than 'oauth_' (how about 'oa_' - 3 bytes instead of 6)?
- johnk
>
> Marius
>
>
>
> On Thu, Apr 15, 2010 at 12:08 PM, John Kemp wrote:
>> Hello,
>>
>> On Apr 15, 2010, at 2:27 PM, Eran Hammer-Lahav wrote:
>>
>
Hello,
On Apr 15, 2010, at 2:27 PM, Eran Hammer-Lahav wrote:
> OAuth 2.0 flows use a single authorization endpoint (with 'type' parameter).
> This endpoint is OAuth-specific but must allow for extension parameters
> (standard or vendor-specific).
>
> The issue is how to best allow for extensions
On Apr 12, 2010, at 3:09 PM, Torsten Lodderstedt wrote:
> Am 12.04.2010 21:00, schrieb Luke Shepard:
If OAuth ever gets to the point where it replaces Basic auth in the
browser,
or used instead of other cookie-based authentication systems, it will gain
native browser support w
On Apr 10, 2010, at 3:05 AM, Torsten Lodderstedt wrote:
> Hi Allen,
>
> as I already posted, I don't think a size limit is a good idea.
+1
>
> Regarding your example: As per RFC-2109, 4KB is the minimum size that must be
> supported by user agents. The maximum size is not restricted:
> "In g
On Apr 8, 2010, at 4:58 PM, Richard Barnes wrote:
> The scope argument doesn't really hold any water, since OAuth isn't defining
> the scope that tokens have -- authorization servers could issue tokens that
> have the same power as passwords. Not all implementors are "reasonable" :)
Indeed, yo
On Apr 8, 2010, at 2:27 PM, Allen Tom wrote:
> Using a bearer token without a signature over HTTP is not equivalent to HTTP
> Basic Auth in the clear.
+1
>
> A bearer token is far less powerful than the user’s password.
s/is/should be/ and I agree ;)
> In most cases, a MITM who steals the
Hi Eran,
On Apr 2, 2010, at 12:18 PM, Eran Hammer-Lahav wrote:
> This is half baked but I wanted to get people's reaction:
>
> Clients tries accessing a resource with or without an access token:
>
> GET /resource/1 HTTP/1.1
> Host: server.example.com
>
> The server replies with:
>
> HTTP/1.1
On Mar 25, 2010, at 9:09 AM, Subbu Allamaraju wrote:
> Just curious - why can't the client check the Date header?
It can. Once it got a failed response from the first call.
Regards,
- johnk
>
> Subbu
>
>
> On Mar 24, 2010, at 6:26 PM, Paul Lindner wrote:
>
>> Right now if a client with an
On Mar 16, 2010, at 8:48 AM, Igor Faynberg wrote:
> That's what I have been thinking. Why is it important to sign the headers?
> (I am not against signing them, but I cannot see the need in the specific
> cases we had discussed. In other words, if I had signed the body of the
> request, I prob
he standards,
URLs may be truncated by *some implementations* (for example).
Regards,
- johnk
>
> On Mar 10, 2010, at 8:30 AM, John Kemp wrote:
>
>> On Mar 10, 2010, at 11:16 AM, Moritz Maisel wrote:
>>
>>> On 03/10/2010 04:42 PM, John Kemp wrote:
>>>> One
On Mar 10, 2010, at 11:16 AM, Moritz Maisel wrote:
> On 03/10/2010 04:42 PM, John Kemp wrote:
>> One reason I can imagine is to make it possible to encode information into
>> the token itself so that the token can be "self-contained" (mentioned also
>> by others
On Mar 9, 2010, at 6:50 PM, David Recordon wrote:
> Ideally we'd limit the length of access and refresh tokens as well as
> client keys and secrets to no more than 255 characters (a one byte
> varchar in MySQL). Is this an issue for anyone?
Yes.
Why would we want to encode such a specific impl
On Mar 8, 2010, at 3:35 PM, Dick Hardt wrote:
>
>
> 2) Client signed tokens are no more secure in MITM attacks than bearer tokens
> for on-the-fly attacks. If the attacker can disrupt the channel, the attacker
> can take the signed token and use it to make a valid call just as if it was a
> b
place in real-world
implementations.
Cheers,
- johnk
>
> Ethan
>
> On Sun, Mar 7, 2010 at 1:40 PM, John Kemp wrote:
>> On Mar 7, 2010, at 12:24 PM, Ethan Jewett wrote:
>>
>> [...]
>>
>>> In my opinion, #5 makes bearer-tokens without SSL/TLS un
On Mar 7, 2010, at 12:24 PM, Ethan Jewett wrote:
[...]
> In my opinion, #5 makes bearer-tokens without SSL/TLS unusable in
> nearly all use cases.
Just to point out that there are many use-cases which are today solved *only*
with "bearer tokens" - namely any authentication method which uses reg
ecurity, of course.
- johnk
>
> This is why I am taking the same position as Eran.
>
> Igor
>
> Eran Hammer-Lahav wrote:
>>
>> On 1/15/10 7:58 AM, "John Kemp" wrote:
>>
>>
>>> When I look at what is possible in the offline world,
Hello Eran,
On Jan 15, 2010, at 4:41 PM, Eran Hammer-Lahav wrote:
>
> On 1/15/10 7:58 AM, "John Kemp" wrote:
>
>> When I look at what is possible in the offline world, I would ask - would you
>> require that movie theatre tickets bought in advance were encryp
On Jan 14, 2010, at 7:39 PM, Richard L. Barnes wrote:
>> As such, I can't see how *not* requiring SSL for unsigned requests
>> could pass muster at an IETF security review.
>
> Speaking as someone who does IETF security reviews ... :)
>
> If I were reviewing a document that defines an optional
Hi Eran!
On Jan 14, 2010, at 11:41 PM, Eran Hammer-Lahav wrote:
> (this is not aimed at John Kemp)
I think you mean it's not _specifically_ aimed at me, but in any case, I'll
take the opportunity to reply anyway ;)
>
> I understand that some providers will not want to bo
sure is
> convenient. :-)
Right, so the URL itself is a bearer token, perhaps with usage limitations,
like a limited timeframe when you get a 200 response from dereferencing the URL
;)
- johnk
>
> Eve
>
> On 14 Jan 2010, at 11:53 AM, Igor Faynberg wrote:
>
>>
On Jan 14, 2010, at 2:15 PM, Igor Faynberg wrote:
> John Kemp wrote:
>> ...
>> And I think there are such cases - rather vaguely I could say that the broad
>> category would be anything for which a large volume of authorized requests
>> is possible, and where t
rather think _is_ deserving of confidentiality
over insecure networks (of course, Gmail does allow you to turn off https if
you are in a more secure network environment).
Regards,
- johnk
>
> [1] http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html
> [2]
> htt
On Jan 14, 2010, at 1:05 AM, Eran Hammer-Lahav wrote:
[...]
>
> QUESTIONS: Are there any valid (such that will pass IETF security review
> scrutiny) reasons for allowing unsigned requests to be sent in the clear
> over an insecure channel? Are there use cases for this (regardless of their
> secu
Hey Eran!
On Jan 9, 2010, at 12:12 PM, Eran Hammer-Lahav wrote:
[...] (sure, agreed)
> My proposed language would be along the lines of "MUST use a secure channel
> such as TLS/SSL or another mechanism providing the same protections". This
> allows not using TLS/SSL when the environment provid
On Jan 8, 2010, at 9:15 PM, Eran Hammer-Lahav wrote:
[...]
> Is there a *good* reason why the 1.0 specification should not mandate using
> a secure channel for PLAINTEXT?
I guess the question is whether you want implementations using other methods to
ensure confidentiality and which don't ne
70 matches
Mail list logo
