Authorization Header Support for Case Insensitive Token Type ("Bearer" vs "bearer") #7
-
|
According to specification, it is clear that supplying an Authorization header and the token type name (Bearer or Basic, etc) should be case sensitive: https://datatracker.ietf.org/doc/html/rfc6750#section-2.1 Today this is currently what Atlas / DevCenter expects and is supported, and it rejects anything as unauthorized with a lowercase "bearer". We have had instances where some APIs in the past were being used internally with lowercase "bearer" and broke in migration to Atlas. I also cannot shake the scenario that this may cost some teams time to debug and understand why their Authorization is not working when I put this against our "Tolerance" design principle: Contracts and consumers are as forgiving as possible without compromising security. This seems like a pretty "easy" case to support that has no security impact that many frameworks already do today. From what I can tell it seems pretty split on support - some stay strict to the RFC's above and others opt to support it to be a bit more friendly following the concepts around: "Be liberal with your input and strict with your output" (lexik/LexikJWTAuthenticationBundle#411). Concrete Examples: Just because Atlas API Gateway would support this easily, doesn't give us complete coverage as services using the Header may have some type of rejection once it reaches their container, but could also likely be mitigated through shared libraries or the fact that most are likely parsing the Authorization value without worrying about the case. I think we should consider the following possible actions:
Thoughts? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
@jwineinger indicates some concern in enabling this now that in the future we may validate the JWT and Authorization header with tooling we do not customize as we do now. So holding on to supporting this for tolerance reasons may make sense rather than introducing it now. We should leave this for now and if it becomes an issue later on we will revisit. |
Beta Was this translation helpful? Give feedback.
-
|
yes, following the spec is the answer :) |
Beta Was this translation helpful? Give feedback.
-
|
So many good things come when people deviate and make things unique :) |
Beta Was this translation helpful? Give feedback.
@jwineinger indicates some concern in enabling this now that in the future we may validate the JWT and Authorization header with tooling we do not customize as we do now. So holding on to supporting this for tolerance reasons may make sense rather than introducing it now.
We should leave this for now and if it becomes an issue later on we will revisit.