Reorganize Security considerations. See #64 #99
Conversation
| disclosure via the communication channel. For those cases where the | ||
| client is prevented from observing the contents of the access token, token | ||
| encryption MUST be applied in addition to the usage of TLS | ||
| protection. As a further defense against token disclosure, the |
There was a problem hiding this comment.
@aaronpk TLS / channel-encryption is already a MUST. This is probably redundant.
There was a problem hiding this comment.
I feel like it's not the worst idea to leave this in, since I've seen plenty of "answers" on stackoverflow that tell people to disable the certificate check in curl to make something work.
There was a problem hiding this comment.
Let's emphasize it in the appropriate sections, so that we can better evolve them in isolation.
It would be interesting instead to identify a section for things like "MUST content encryption".
I'll wait for #99 and come back later on that though :) Thanks for your support! R.
| See "HTTP State Management Mechanism" {{RFC6265}} for security | ||
| considerations about cookies. | ||
|
|
||
| In some deployments, including those utilizing load balancers, the |
There was a problem hiding this comment.
I think the problem is quite clear. I won't restate it from scratch. Instead I created a separate section wrt Intermediaries above.
| to protected resources, including checking the Certificate Revocation | ||
| List (CRL) {{RFC5280}}. | ||
|
|
||
| If cookies are transmitted without TLS protection, any |
There was a problem hiding this comment.
All considerations on cookies could be collected and placed in a subsection.
| confidentiality of the access token between the front-end and back-end | ||
| servers; encryption of the token is one such possible measure. | ||
|
|
||
| To deal with access token capture and replay, the following recommendations |
There was a problem hiding this comment.
Reworked as a list. Still I won't re-state all possible problems that TLS solves (eavesdropping, impersonation, integrity, ..) :)
|
This is a great start. We'll come back to it after #98 is merged. |
| MUST require the use of TLS on every endpoint used for end-user | ||
| interaction. | ||
| See {{communication-security}} for further details | ||
| on mitigating the risk of phishing attacks. |
| token endpoints. The client MUST validate the authorization server's | ||
| TLS certificate as defined by [RFC6125] and in accordance with its | ||
| requirements for server identity authentication. | ||
| The risk related to man-in-the-middle attacks is mitigated by the |
| protected part of the token. Short-lived tokens reduces both the probablity and the impacts of a leak. | ||
| 2. protect the confidentiality of the communication between the client and the RS | ||
| to mitigate the risk of eavesdropping; | ||
| 3. the client MUST verify the identity of the resource server before |
There was a problem hiding this comment.
To this end, one thing which is currently lacking is a standard/recommended way for the AS to communicate to the client the intended audience(s) (URLs) of the issued access token.
This PR
Needs #98