Case sensitivity of AccessTokenPrefix is not properly handled

[chikashi]

In regards to AccessTokenPrefix , there's no option to make access token prefix case insensitive.

By default, "Bearer" value with a capital B can only be accepted.  

It needs to be case insensitive according to rfc6749#section-5.1 

>token_type
>REQUIRED. The type of the token issued as described in
>Section 7.1. Value is case insensitive.

A workaround is transforming the header value before  VerifyAccessToken operation but it is not ideal. 

Does Apigee team have any plan to support case insensitive access token prefix?

[dchiesa1]

I think you are mis-interpreting the specification. Section 5.1, which you cited, describes the RESPONSE to a request-for-token. It does not apply to the usage of such a token. In the response to a request-for-token, the token_type field can be case-insensitive, according to this spec:

You can see that it refers to Section 7.1 of RFC6749, which describes some different token types, including Bearer and Mac, and gives some examples of usage. This section refers to RFC6750 for the formal definition of how to use bearer tokens.

RFC 6750, entitled "Bearer Token Usage" describes how clients must pass tokens when making authenticated requests, which is the scenario you are discussing. This spec says they should pass them in the Authorization header with the "Bearer" prefix. This spec does not say anything about case-insensitivity. The formal definition states that the prefix must be "Bearer". See section 2.1.

So I think Apigee's OAuthV2 policy (with Operation=VerifyAccessToken) is in compliance with the relevant specification, IETF RFC 6750.

There is no plan to alter the policy to accept a case-insensitive prefix.

I guess you should tell your client app developers to use Bearer with an uppercase B, and refer them to RFC6750, section 2.1.

[chikashi]

@dchiesa1 

Thank you for answering.  And I apologize for my misinterpretation.   

The reason why I’m asking is I’m running a test suite of FAPI 2.0 provided by OpenID Foundation.

https://openid.net/certification/certification-fapi_op_testing

Test Name :  fapi2-security-profile-id2-access-token-type-header-case-sensitivity

In the test suite, there’s a test case that ensures “Bearer” is case-insensitive. 

The test triggers a request against resource server with a following header. 

"Authorization": "bEARER 4XsVynX-TnhbYaNCdPdxwZ87qCDKNjp679-J4ZJGyZc"

Therefore, it is not the situation that we can tell client to use Bearer with an uppercase B.  

If "AccessTokenPrefix" supports regex or case-insensitive, it’s helpful for us. 

I appreciate if you consider this feature as a possible option. 

Thanks. 

[dchiesa1]

Ahh, I see.

Maybe I need to back off my earlier statement.

I can understand the confusion. Section 2.1 of RFC6750 states clearly that the prefix is "Bearer" several times, and does not state anything about case-insensitivity. It's very clear. And section 1.1 of RFC6750 states unequivocally: "Unless otherwise noted, all the protocol parameter names and values are case sensitive." Despite that, there is the "case insensitive" remark in section 2.1 of RFC 6749 for an adjacent part of OAuth: the response for the request-for-token. This is not referring to the use of the token, which is covered in RFC 6750. This lack of consistency seems to confuse some people, and that is understandable . Added to that, while RFC 6750 section 1.1 insists that the parameters mentioned in the spec are case sensitive, section 2.1 of RFC 6750 refers to RFC 2617 section 1.2, which describes the general model for "Authentication schemes" for HTTP, and which states that the Authorization header should use a prefix to identify the authentication scheme, and that prefix should be ... case insensitive!. But RFC2617 says that the auth scheme should be followed by name=value pairs, which OAuthV2 definitely does not use, therefore it's clear that RFC2617 is not fully authoritative. 

The problem with this inconsistency in the related specifications has been noted by others. (example 1, example 2, example 3).

I have filed a request to modify Apigee so that it would be possible to relax its exact-case check of the AccessTokenPrefix (internal reference: b/301617815).   But I am not sure how the product team will prioritize such a request, especially given the ambiguity in the specs, and the easy workarounds: 1) have the clients do the right thing, and 2) use ExtractVariables to avoid the problem.

Thanks for reporting this and engaging in the discussion. 

[chikashi]

I appreciate your confirmation. I contacted an OIDF member and asked where this specification originally came from.  He quoted RFC 7235, which is the successor to the RFC 2617 you mentioned.  The answer was as follows:

>The case-insensitivity is based on the HTTP specification, not on OAuth/FAPI specifications.

>RFC 7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication, 2.1. Challenge and Response

> uses a case-insensitive token as a means to identify the authentication scheme, followed by additional information necessary for >achieving authentication via that scheme.

I understand that the workaround is simple. However, as this is supposed to be enforced by multiple API proxies (resource servers), redundant boilerplate flow callouts are inevitable. 

Thank you for filing a modification request. 

[MarciSoos]

Hi Gentlemen!

This topic has just popped up on our side, so I'm really happy that I've found this conversation. Let me share my thoughts and conclusion.

rfc2617 is obsoleted by
1) rfc7235 and rfc7615 that are both obsoleted by rfc9110 
2) rfc7616 -> Digest
3) rfc7617 -> Basic

Furthermore, my understanding is that rfc2617 has been always only about basic and digest, and not about using (bearer) tokens.
So yes, basic/digest has been case-insensitive since rfc2617, and it is case-insensitive as per rfc7616 / rfc7617 too, but it is nothing to do with the usage of (bearer) token.
So I think that these rfc's are not relevant here at all, and I really don't understand why the OIDF member cited those.

rfc9110 auth-scheme points to the HTTP Authentication Scheme Registry 
that points to rfc6750, where - in my opinion - the most relevant statement is what Dino has been cited already:

Unless otherwise noted, all the protocol parameter names and values are case sensitive.

I agree with Dino's conclusion, that is

1. It's more 'likely' that Bearer meant to be case-sensitive
2. It would be great to have some clarification about this topic in one of the rfcs (maybe with exact 'manual' what SOULD (NOT), MUST (NOT) to do)

Another question:

Do you think that only Bearer is acceptable? I encountered the usage of other 'key'words, like 'JWT', 'Token' etc.

Because of I am really not comfortable with the current situation, I have also dropped an email with these concenrs to the authors of the rfc6750.

Br,
Marcello

[MarciSoos]

Hi @dchiesa1 , @chikashi ,

I received the response from Dick Hardt who is the one of the authors of rfc6750.

Questions

1. Is the Bearer keyword case-sensitive in requests, so only Bearer is acceptable, any others MUST NOT be accepted?

2. Is the Bearer the one and only acceptable word, or proxies/servers SHOULD / MUST accept eg. JWT, Token etc.

3. Is it possible to clarify the 1. and 2. questions of Bearer usage in RFC6750 or in other rfc-s?

Answers:

 So I think that b/301617815 should not be implemented, and clients must provide always Bearer.

Br and a happy new year,

Marcello

[chikashi]

Thanks for getting involved in the further discussion.
Based on this conversation, I will make a request to the OIDF guy to consider modifying their test for FAPI 2 regarding the case : “fapi2-security-profile-id2-access-token-type-header-case-sensitivity”