Hi all, Rifaat and I went through the discussion in an effort to judge the outcome.
First, we would like to thank you all for your input. Torsten, as the editor of the OAuth Security BCP, got lots of good feedback. Second, there is strong support recommending against the implicit grant and the response types "token id_token" and "code token id_token" for all future applications. For already deployed applications please do your threat analysis and make your own judgement. Here is a proposal for the new text in Section 2.1.2 of the Security BCP: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10 ---- 2.1.2. Implicit Grant The implicit grant (response type "token") and other response types causing the authorization server to issue access tokens in the authorization response are vulnerable to access token leakage and access token replay as described in Section 3.1, Section 3.2, Section 3.3, and Section 3.6. Moreover, no viable mechanism exists to cryptographically bind access tokens issued in the authorization response to a certain client as it is recommended in Section 2.2. This makes replay detection for such access tokens at resource servers impossible. In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type "token") or any other response type issuing access tokens in the authorization response, such as "token id_token" and "code token id_token", unless the issued access tokens are sender-constrained and access token injection in the authorization response is prevented. A sender constrained access token scopes the applicability of an access token to a certain sender. This sender is obliged to demonstrate knowledge of a certain secret as prerequisite for the acceptance of that token at the recipient (e.g., a resource server). Clients SHOULD instead use the response type "code" (aka authorization code grant type) as specified in Section 2.1.1 or any other response type that causes the authorization server to issue access tokens in the token response. This allows the authorization server to detect replay attempts and generally reduces the attack surface since access tokens are not exposed in URLs. It also allows the authorization server to sender-constrain the issued tokens. ---- There was a lot of feedback for advice on how to implement OAuth with single-page applications. Aaron has been working on a draft and we are planning to start a call for adoption. This document will be a natural home for describing solutions. Here is the link to the draft: https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02 Ciao Hannes & Rifaat PS: We would like to remind you about the upcoming OAuth Security Workshop in Stuttgart/Germany (March 20-22, 2019) where we will speak about the above-mentioned topics and much more. Here is the link: https://sec.uni-stuttgart.de/events/osw2019 From: Hannes Tschofenig Sent: Montag, 19. November 2018 11:34 To: oauth <oauth@ietf.org> Subject: OAuth Security Topics -- Recommend authorization code instead of implicit Hi all, The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01). A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list. Please provide a response by December 3rd. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
