[OAUTH-WG] Authorization Header Encoding

[Justin Richer]

The HTTP Working Group opened an issue for discussion in relation to the 
updated HTTP semantics specification. The core of the issue is the format of 
the “Authorization” header, which of course gets used by the “Bearer” scheme 
defined in RFC6750.

https://github.com/httpwg/http-core/issues/733 


As it turns out, Bearer defines a more limited character set than is allowed by 
core HTTP, and doesn’t follow the HTTP guidelines and definitions for the 
Authorization header. There were a few observations on the call:

 - The Bearer spec was limited because OAuth tokens were also allowed in HTTP 
URLs and form parameters (and therefore had to have a more limited character 
set)
 - In practice people don’t actually restrict the values they put into this 
field; pretty much any implementation is just going to concatenate whatever 
access token value they get to the magic word “Bearer” and send it
 - It’s not likely (or in my opinion proper) for the HTTP spec to change to 
address the oddities of RFC6750 and decisions that were made many years ago

So the question is, what do we do about it? We could do a revision of 6750 that 
reflects reality better, pretty much just changing the ABNF.

Or, we could update the definition of the Bearer header in the upcoming OAuth 
2.1 specification.

Are there other options?

 — Justin

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

[Andrii Deinega]

Hi Vladimir,

What would be a value in the aud claim for refresh tokens?

Regards,
Andrii


On Tue, Feb 9, 2021 at 3:06 AM Vladimir Dzhuvinov 
wrote:

> Hi Warren,
> On 08/02/2021 17:59, Warren Parad wrote:
>
> None of that justified explicitly stating that refresh token introspection
> shouldn't be done. At best it suggests that we should explicitly add
> language in the draft to directly encourage it.
>
> Did you mean discourage?
>
> But if an AS wants to support it, we shouldn't stop them, or suggest that
> they can't do it.
>
> The current draft doesn't mention refresh tokens at all. Its subject is
> the introspection of access tokens by authenticated resource servers and
> returning the response as a signed JWT. The use of refresh tokens at the
> introspection endpoint, per RFC 7662, is not forbidden by the draft.
>
>
>
> Allowing refresh tokens to be introspected can also create a conflict with
>> the sec recommendation to rotate them
>
>
> Not following, can you explain this further?
>
> I just double checked the rotation spec. Use that triggers rotation is
> clearly specified as "access token response", so there should actually be
> no issues with confusing introspection as use.
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.13.2
>
> RFC 7662 also seems to imply that a public client with a refresh token
> should not normally be able to introspect it, because it can't authenticate
> to the AS.
>
> https://tools.ietf.org/html/rfc7662#section-2.2
>
>To prevent token scanning attacks, the endpoint MUST also require
>some form of authorization to access this endpoint, such as client
>authentication as described in OAuth 2.0 [RFC6749 
> ] or a separate
>OAuth 2.0 access token such as the bearer token described in OAuth
>2.0 Bearer Token Usage [RFC6750 ].  
> The methods of managing and
>validating these authentication credentials are out of scope of this
>specification.
>
>
> Vladimir
>
>
>
> Warren Parad
>
> Founder, CTO
> Secure your user data and complete your authorization architecture.
> Implement Authress .
>
>
> On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov 
> wrote:
>
>> At first it may appear that allowing refresh tokens at the introspection
>> endpoint may be a logical thing to do, but in practice there are issues
>> with that and from an OAuth 2.x perspective it's not easy to justify.
>>
>> If the point is to let clients check what authorization they have been
>> given OAuth 2.0 already provides a std way to do that - in the access token
>> response - the "scope" parameter:
>>
>> https://tools.ietf.org/html/rfc6749#section-5.1
>>
>> RAR has a similar parameter:
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1
>>
>> If the point is to find if a refresh token is still valid - this can be
>> found out by simply using it. Allowing refresh tokens to be introspected
>> can also create a conflict with the sec recommendation to rotate them. So
>> thus it may be a better idea to not let clients assume too much about them.
>>
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.2.2
>>
>> If the AS is going to expose refresh token data to a client it will also
>> have to make a careful judgement what data it exposes.
>>
>> https://tools.ietf.org/html/rfc7662#section-2.2
>>
>> For instance "sub". OAuth 2.x in the relation between AS and client
>> actually has no concept or definition of subject / end-user identifier. And
>> this is done for a good reason, because it's not a user authentication
>> protocol. OIDC was designed for that. And to prevent tracking of users and
>> other privacy issues OIDC also specifies pairwise subject IDs. The plain
>> OAuth 2.x world doesn't have this.
>>
>> Vladimir
>> On 08/02/2021 11:07, Warren Parad wrote:
>>
>> It doesn't work that way. You suggested to add language to the draft,
>> that means the burden of proof is on you to justify adding it.
>>
>> Otherwise I could just say why not?
>>
>> And I can go stronger, what's the purpose of nho introspection endpoint
>> at all, and why encourage sending access tokens to the AS?
>>
>> Even if you can justify access tokens, there currently isn't evidence
>> provided why we should explicity discourage.
>>
>>
>> On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt 
>> wrote:
>>
>>>
>>>
>>> Am 08.02.2021 um 00:56 schrieb Warren Parad :
>>>
>>> 
>>>
 I‘m therefore leaning towards explicitly stating in our draft that it
 is not intended to be used with refresh tokens.
>>>
>>> I'm not following, why explicitly state that it isn't intended. If an AS
>>> wants to provide a similar JSON response to a query with the refresh token,
>>> why not encourage that?
>>>
>>>
>>> Why should we encourage it?
>>>
>>>
>>> Warren Parad
>>>
>>> Founder, CTO
>>> Secure your user data and complete your authorization architecture.
>>> Implement A

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

[Andrii Deinega]

Thank you for the response! Unfortunately, I'm still not convinced that
there is no need for nonce.



Based on the draft, I don't know how it's possible to achieve a “stronger
assurance that the authorizationserver issued the token introspection
response for an access token, includingcases where the authorization server
assumes liability for the content of thetoken introspection response
”
if we can't guarantee that a client will always get the response to its
initial introspect request, or in other words, old communications can be
never reused (the iat claim isn't going to be sufficient for that).



Let's put aside those attackers for a moment and say we experience some
awfully wrong caching issues that can happen anywhere between an AS and a
client... where the client gets a cached response for its previous requests
which isn't expected. How can it be prevented?


Regards,

Andrii



On Wed, Feb 10, 2021 at 12:15 AM Neil Madden 
wrote:

>
> On 9 Feb 2021, at 22:04, Andrii Deinega  wrote:
>
> 
> I still don't see how your #1 and #3 points mitigate the replay attack
> when an attacker somehow eavesdrops a successful response from an AS (yes,
> it's signed by a public key) and then starts to replay it for other
> requests from the same client.
>
>
> The point of #1 is that an attacker that has compromised the communication
> channel between the AS and client can do much more than replay
> introspection responses. In particular they can replace the AS’s public key
> with their own and then sign their own introspection JWTs, with whatever
> nonce in them that they like (they can easily see the nonce in the
> request).
>
> They can also steal access tokens and almost certainly also steal user
> session cookies and manipulate authorization responses from users to change
> the scopes that are approved for different requests.
>
> It’s absolutely essential that ASs and clients ensure the TLS connection
> between them is secure.
>
> The stated purpose of JWT introspection responses is for non-repudiation.
> It’s not intended as a replacement for TLS. Within that context “iat” is
> sufficient proof of freshness.
>
>
> The main problem here is that the client doesn't have a way to correlate
> the introspection response with the initial introspection request.
>
>
> In a properly secured environment this guaranteed by TLS (and even TCP).
>
>
> Regarding #2, it's true that there are many proxies that do this and that.
> In practice, you don't always have control over the infrastructure where
> you may run your AS as I was saying before.
>
>
> Right - so trying to solve this issue by replacing TLS with another
> technology that is just as susceptible to the problem is not a real
> solution.
>
> — Neil
>
>
> ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth