[OAUTH-WG] Conclusion ... OAuth Security Topics -- Recommend authorization code instead of implicit

[Hannes Tschofenig <[e-mail]>]

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 <[e-mail]>
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.