Subject: [OAUTH-WG] RFC 7009: Revoke Access Tokens issued to HTML5 web apps

From: <[email-masked]>
Date: Fri, 19 Feb 2016 11:14:54 +0000

Hi,

we use the OAuth 2.0 Implicit grant to issue access_tokens to client applications such as HTML 5 web apps that have no secure means to securely authenticating themselves. Even if the credentials would be obfuscated, any user could extract them from the HTTP requests their User Agent makes with minimal effort. Since RFC 7009 also talks about the usage of CORS to support User-Agent clients, however, I believe that these clients should be supported.

So I am having trouble supporting the revocation requirement in RFC 7009 which states:

   The client also includes its authentication credentials as described

   in Section 2.3. of [RFC6749]<https://tools.ietf.org/html/rfc6749#section-2.3>.

Looking at said section in in RFC 6749, it states:

   If the client type is confidential, the client and authorization

   server establish a client authentication method suitable for the

   security requirements of the authorization server.  The authorization

   server MAY accept any form of client authentication meeting its

   security requirements.

I am unsure whether "having no form of client authentication" conforms to the standard, can you comment on this?

As a side note, I wonder why client authentication for token revocations is required anyway, because if a client received a token by any legit means, it should always be able to revoke it, regardless of authentication. And if an unauthorized client 'stole' any type of token, revoking it should also be possible, since loss of service for the intended client should always be preferred over misusing the token.

Cheers,

Thomas

BMW Group
Thomas Kupka
Customer Data Management, FG-6301
GCDM Identity & Access Management
Bremer Straße 6
80807 München

Postanschrift:
80788 München

Tel: +49-89-382-54083
Mail: [email-masked]<mailto:[email-masked]>
Web:  http://www.bmwgroup.com/
--------------------------------------------------------
Bayerische Motoren Werke Aktiengesellschaft
Vorstand: Harald Krüger (Vorsitzender),
Milagros Caiña Carreiro-Andree, Klaus Draeger,
Friedrich Eichiner, Klaus Fröhlich, Ian Robertson,
Peter Schwarzenbauer, Oliver Zipse.
Vorsitzender des Aufsichtsrats: Norbert Reithofer
Sitz und Registergericht: München HRB 42243
--------------------------------------------------------

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 28 Feb 2016 16:44:45 +0100

Hi Thomas,

see comments inline.

Am 19.02.2016 um 12:14 schrieb [email-masked]:
>
> Hi,
>
> we use the OAuth 2.0 Implicit grant to issue access_tokens to client 
> applications such as HTML 5 web apps that have no secure means to 
> securely authenticating themselves. Even if the credentials would be 
> obfuscated, any user could extract them from the HTTP requests their 
> User Agent makes with minimal effort. Since RFC 7009 also talks about 
> the usage of CORS to support User-Agent clients, however, I believe 
> that these clients should be supported.
>
> inSection 2.3. of [RFC6749] 
> <https://tools.ietf.org/html/rfc6749#section-2.3>.
>
> I am unsure whether “having no form of client authentication” conforms 
> to the standard, can you comment on this?
>

Yes, it does. The client shall use the authentication means it would use 
on the AS's token endpoint as well. And in the same way as public 
clients only identify themself in this use case, they are supposed to do 
the same at the revocation endpoint.

> As a side note, I wonder why client authentication for token 
> revocations is required anyway, because if a client received a token 
> by any legit means, it should always be able to revoke it, regardless 
> of authentication. And if an unauthorized client ‘stole’ any type of 
> token, revoking it should also be possible, since loss of service for 
> the intended client should always be preferred over misusing the token.
>

Good catch :-) We discussed this when we went through WG review. The 
position we finally decided to take is: what is the worst thing an 
attacker could do on the revocation endpoint? It would revoke tokens in 
order to interupt the respective service for the resource owner. 
Requiring authentication will prevent this.

best regards,
Torsten.

> *BMW Group*
> Mail: [email-masked] <mailto:[email-masked]>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth