Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

[Nat Sakimura <[e-mail]>]

Well, re-reading, I have a bit of problem with the draft.

It is defining a new concept 'issuer', which is not found in RFC6749, as
the authorization server's configuration information location. It is
returned in 'iss' authorization response parameter. On the other hand,
there is an existing concept of 'issuer' for identifying the authorization
server in OpenID Connect. e.g., Google's discovery document's URI is
https://accounts.google.com/.well-known/openid-configuration and issuer in
it is https://accounts.google.com . This value MUST exactly match the "iss"
in ID Token.
Unfortunately, this does not match the value of OAuth issuer defined in
Section 2 of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned
as specified in 3.1. As such, validation as specified in bullet 1 of
Section 4 fails in Google's case -- OR it means that the document is
internally inconsistent.

Also, I do not understand the value of OAuth issuer when there is no
configuration file but everything is determined in the developer
documentation. This is one of the assumption of RFC6749 and many OAuth
servers are operated like that. Technically, since the discovery document
does not exist, it is an empty string, which fails the validation rule set
here.

As to section 5 is concerned, I could not read out what threat it is trying
to mitigate. Is it trying to address the case that the client is not doing
a proper state check? From section 6, it seems it is trying to do the
binding between the authorization request and the token request, but if
that is the case, is it not better to just use PKCE than introducing
something new?

The draft-sakimura-oauth-meta-05 approach is similar, but it avoids these
confusions.
Instead of relying on 'issuer' concept, it uses token endpoint URI. Per
discussion in Yokohama, the identifier that distinguishes the authorization
server is the URI of the authorization endpoint uri. This is the trust
anchor of the entire flow, and it exists even if the client is not using
discovery of any kind. If you cannot trust this endpoint, everything
breaks. Oauth-meta chains the trust through metadata step by step.

In case of 'code' flow, the next step on the server side is the token
endpoint uri. This is returned in a parameter called 'turi', a shorthand
for token endpoint uri. The validation rule is that the client MUST check
that turi and the token endpoint uri that is previously known to the client
exactly matches. (Actually, a simpler way is just use the value returned in
turi.)

Then, the client sends the token request to turi. If additional security
through authorization and token request binding, or making sure that the
client instance is really the intended audience, then use PKCE [RFC7636].
The client_id parameter in draft-jones-oauth-mix-up-mitigation-01 does not
help in the case of public client, but PKCE works.

In addition, draft-sakimura-oauth-meta-05
<https://tools.ietf.org/html/draft-sakimura-oauth-meta-05> [1] provides
other goodies as well, such as HATEOAS. It achieves all these by the full
use of RFC5988 and introducing very little new things. It is only one page!

So, IMHO, the combination of draft-sakimura-oauth-meta-05 and RFC7636 seems
to be a better solution.

   - It does not break the existing implementations;
   - It does not confuse the reader by defining two concepts of issuer
   depending on the context;
   - It works in the case that the configuration is done through the
   developer documentation. i.e., it does not require yet to be defined
   discovery spec.
   - It works for public client as well;
   - It enables HATEOAS - Yes. It makes OAuth finally RESTful!;

There is one discussion point that I want to raise for oauth-meta.
Currently, the authorization response metadata such as turi are returned as
query parameters. This is to enable the dynamic reallocation of the
endpoints, and adhere to the HATEOS principle. If you do not need this
dynamism, then there is an alternative proposal that I have, that makes it
extremely simple to implement for the server. In this case, the client just
sends HEAD request to the authorization endpoint. Then the authorization
endpoint returns 200 OK with turi in the header. e.g.,

 HTTP/1.1 200 OK
   Link: <https://example.com/token>; rel="turi",
   Content-Type: application/JSON; charset=utf-8


This can be achieved without touching the authorization endpoint code, but
just by configuration. In case of apache, use 'header append' in the apache
configuration. If we take this course, then there is another advantage to
be added:

   - You do not need to change the server code.

Is it not attractive?

Cheers,

Nat Sakimura

[1] https://tools.ietf.org/html/draft-sakimura-oauth-meta-05


2016年1月21日(木) 15:14 Antonio Sanso <[e-mail]>:

> +1 for adoption
> On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig <[e-mail]>
> wrote:
>
> > Hi all,
> >
> > this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
> > https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
> >
> > Please let us know by Feb 9th whether you accept / object to the
> > adoption of this document as a starting point for work in the OAuth
> > working group.
> >
> > Note: This call is related to the announcement made on the list earlier
> > this month, see
> > http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
> > time for analysis is provided due to the complexity of the topic.
> >
> > Ciao
> > Hannes & Derek
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>