Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd authorization header to simple set as well as suggest its usage #93
Conversation
|
Any update? |
| @@ -627,7 +627,7 @@ Add an Access-Control-Max-Age pref response header containing the number of seco | |||
| Because browser preflight response caches are notoriously weak, the additional round trip from a preflight response hurts performance. | |||
| Services used by interactive Web clients where performance is critical SHOULD avoid patterns that cause a preflight request | |||
| - For GET and HEAD calls, avoid requiring request headers that are not part of the simple set above. Allow them to be provided as query parameters instead. | |||
| - The Authorization header is not part of the simple set, so the authentication token MUST be sent through the "access_token" query parameter instead, for resources requiring authentication. Note that passing authentication tokens in the URL is not recommended, because it can lead to the token getting recorded in server logs and exposed to anyone with access to those logs. Services that accept authentication tokens through the URL MUST take steps to mitigate the security risks, such as using short-lived authentication tokens, suppressing the auth token from getting logged, and controlling access to server logs. | |||
| - The Authorization header (AH) SHOULD be used as method of providing authentication information (thus, can be included in the simple set). AH provides authentication of the IP header and next-level protocol data. Security services are initiated between two communicating hosts, between two communicating security gateways or between a security gateway and a host. Note that passing authentication tokens in the URL is not recommended, because it can lead to the token getting recorded in server logs and exposed to anyone with access to those logs. Services that accept authentication tokens through the URL MUST take steps to mitigate the security risks, such as using short-lived authentication tokens, suppressing the auth token from getting logged, and controlling access to server logs. | |||
This comment has been minimized.
This comment has been minimized.
darrelmiller
Sep 14, 2017
Member
I think just a minor modification to the last part of the paragraph is what is needed. e.g.
Although the Authorization Header is not part of the CORS simple set, passing authentication tokens in the URL is not recommended, because it can lead to the token getting recorded in server logs and exposed to anyone with access to those logs. Services that accept authentication tokens through the URL MUST take steps to mitigate the security risks, such as using short-lived authentication tokens, suppressing the auth token from getting logged, and controlling access to server logs.
I don't think we need to start trying to explain what the Authorization Header is, or how it can be used.
This comment has been minimized.
This comment has been minimized.
|
@darrelmiller just updated the changes. I think it should be good now. By the way, when writing this guidelines, what web resources did you use? |
|
Thanks for the update. I wasn't involved when the original guidelines were being written but I'm guessing that many different sources were used to derive these guidelines. |
|
Thanks both. We seem to have lost in the shuffle that if you HAVE to pass the token in the URL due to your perf requirement, then the way to do it MUST be to use the "access_token" query parameter, which seems to be encoded in the initial intent of the paragraph. or am I missing something. |
|
@garethj-msft You are correct, we dropped that. I guess I read what I expected to read. I didn't expect the guidelines to enforce a query parameter name. I see the value in doing that, but my gut is telling me that's a bad idea. I need to think about that some more. But regardless, the existing guidance says it MUST be "access_token" so we shouldn't change that in this PR. |
oneturkmen commentedAug 17, 2017
PR relates to issue #91.