Bearer Token - Revision history

Tom: /* Secure Transfer */

2022-04-05T19:51:19Z

‎Secure Transfer

Tom: /* Secure Transfer */

2022-04-05T19:50:26Z

‎Secure Transfer

Tom: /* Solution */

2022-04-05T19:49:08Z

‎Solution

Tom: /* Solution */

2019-12-18T19:49:03Z

‎Solution

Tom: /* Solution */

2019-12-18T19:48:40Z

‎Solution

Tom: /* Problem */

2018-10-03T04:30:09Z

‎Problem

Tom: /* Problem */

2018-10-03T04:27:27Z

‎Problem

Tom: /* Problem */

2018-10-02T18:56:50Z

‎Problem

Tom: /* Problem */

2018-10-02T18:34:50Z

‎Problem

Tom: /* Context */

2018-10-02T18:34:00Z

‎Context

@@ Line 21: / Line 21: @@
 *The [[Sender Constrained Token]] ensures that the there is some binding of the token to a credential in the possession of the [[Subject]].
 ===Secure Transfer===
-One way to make bearer tokens more secure is to protect the transport protocol. Note that this is just a mitigation of the threat and not a comprehensive solution.
+One way to make bearer tokens more secure is to protect the transport protocol. Note that this is just a mitigation of the threat and not a comprehensive solution. So, this can be considered as an updated version of channel binding.
 * [https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html Secure Credential Transfer]

@@ Line 21: / Line 21: @@
 *The [[Sender Constrained Token]] ensures that the there is some binding of the token to a credential in the possession of the [[Subject]].
 ===Secure Transfer===
-One way to make bearer tokens more secure is to protect the transport protocol.
+One way to make bearer tokens more secure is to protect the transport protocol. Note that this is just a mitigation of the threat and not a comprehensive solution.
 * [https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html Secure Credential Transfer]

@@ Line 20: / Line 20: @@
 *Protection from the secure channel endpoint to a front end server is not the same as a binding directly to the [[Subject]].
 *The [[Sender Constrained Token]] ensures that the there is some binding of the token to a credential in the possession of the [[Subject]].
 ==Reference==

@@ Line 19: / Line 19: @@
 *John Bradly created RFC on token binding which was supported by Microsoft browsers with [[Channel Binding]] but Google found [https://twitter.com/__b_c/status/1030561000724942848 reasons for token binding] not persuasive and dropped support.
 *Protection from the secure channel endpoint to a front end server is not the same as a binding directly to the [[Subject]].
-*The [[Sender Contained Token]] ensures that the there is some binding of the token to a credential in the possession of the [[Subject]].
+*The [[Sender Constrained Token]] ensures that the there is some binding of the token to a credential in the possession of the [[Subject]].
 ==Reference==

@@ Line 18: / Line 18: @@
 *Microsoft introduced EAP and [[Channel Binding]]
 *John Bradly created RFC on token binding which was supported by Microsoft browsers with [[Channel Binding]] but Google found [https://twitter.com/__b_c/status/1030561000724942848 reasons for token binding] not persuasive and dropped support.
-*Protection from the secure channel endpoint to a front end server
+*Protection from the secure channel endpoint to a front end server is not the same as a binding directly to the [[Subject]].
 ==Reference==

@@ Line 9: / Line 9: @@
 *Any party in possession of a [[Bearer Token]] can use it to get access to the associated [[Resource]]s.  To prevent misuse, bearer tokens need to be  protected from disclosure in storage and in transport.
 *[[Bearer Token]]s are valid only for as short time as possible. These tokens work like passwords, and if intercepted can be used immediately by an attacker. Therefore the OAuth2 (with bearer token) specification requires that all communication takes place over SSL - since no cryptography is built into the specification. Typically access tokens have a short validity, which can be refreshed with a "refresh token" which has longer validity but is only transferred when the initial bearer token is received by the consumer, and when a bearer token is refreshed.
-*Microsoft reported the replay attack against Kerberos tokens<ref>Microsoft Security Advisory 974926, ''Credential Relaying Attacks on Integrated Windows Authentication'' (2009-12-08) https://docs.microsoft.com/en-us/security-updates/securityadvisories/2009/974926</ref> and addressed the attack with [[Channel Binding]].
+*Microsoft reported the replay attack against Kerberos tokens<ref>Microsoft Security Advisory 974926, ''Credential Relaying Attacks on Integrated Windows Authentication'' (2009-12-08) https://docs.microsoft.com/en-us/security-updates/securityadvisories/2009/974926</ref> and addressed the attack with [[Channel Binding]].<ref>Microsoft Directroy Services Team, ''Control Extended Protection for Authentication using Security Policy.'' https://blogs.technet.microsoft.com/askds/2009/12/10/control-extended-protection-for-authentication-using-security-policy/</ref>
 *Token reuse: [[OAuth 2.0]] or [[OpenID Connect]] use of bearer tokens raises the risk of token theft. For years architects have been waiting for [[Token Binding]] to get ratified so there would be transparent mechanism to close this gap. If this feature gets dropped from Chrome, this enterprise use case doesn't go away and only Microsoft Browsers support the feature.
 *[https://www.pingidentity.com/en/company/blog/posts/2018/token-binding-a-critical-turning-point-for-securing-identity.html?mkt_tok=eyJpIjoiWXpZeFl6WXdNVFE0T1RNMyIsInQiOiJqdmZFOU1ITUo0ZGJXbjhVUGVSOTBsempZbnR0Qmd4cTQxWE1FMkhnMDY5N2k3SE9uakszWFBWRlViOVlUTDBZWmtyMjF3ZlZyMnN4M01ONnZIdHlHdXd2Slgyc1dKNVljU2hhcGlIZU5ZUnYrZ3NQY1JWNXhIWkVzdEswVHZ6MSJ9 Sarah Squire on Token  Binding]]

@@ Line 4: / Line 4: @@
 ==Context==
 RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer Token Usage" defines the [[Bearer Token]].
 ==Problem==