[OAUTH-WG] Re: Feedback on draft-ietf-oauth-first-party-apps-00

[Pieter Kasselman <[e-mail]>]

Thanks Janak for your detailed review and opening the GitHub issues.

On Wed, Nov 13, 2024 at 9:39 AM Janak Amarasena <[e-mail]>
wrote:

> Hi All,
>
> I created GitHub issues[1] #125 to #131 covering the feedback I provided
> through my previous email.
>
> [1] - https://github.com/oauth-wg/oauth-first-party-apps/issues
>
> Best Regards,
> Janak Amarasena
>
> On Fri, Nov 1, 2024 at 11:43 AM Janak Amarasena <[e-mail]>
> wrote:
>
>> Hi All,
>>
>> I have gone through the OAuth 2.0 for First Party Applications draft (
>> draft-ietf-oauth-first-party-apps-00) and have some feedback on it. I
>> think this is a much needed standard. At my organization(WSO2) also we have
>> seen a significant demand from customers requesting to do API centric
>> authorization largely due to the need for seamless UX. We have seen places
>> where organizations lean more towards UX disregarding security best
>> practices. Due to the demand we ourselves did an extension for OAuth to
>> solve the same problem this specification is addressing and at the time if
>> this specification existed we would have definitely implemented this
>> without going ahead with our own extension.
>>
>> Please find my feedback below;
>>
>> Under section 5.1. “Authorization Challenge Request” the spec lists the
>> “code_challenge” and the "code_challenge_method" as optional parameters. As
>> this protocol establishes direct communication between the client and the
>> AS I don’t see a real requirement to mention PKCE related parameters
>> here. Please let me know if I have missed anything here.
>>
>> As I understood, using these two parameters in the authorization
>> challenge request is useful only when the client expects that it will have
>> to perform a redirect based authorization flow and also the AS supports PAR
>> capabilities through the authorization_challenge_endpoint. I think this
>> will be an edge case and given the spec mentions it supports all extensions
>> applicable to the authorization endpoint I don’t see a major need to
>> specifically mention these two parameters under this section. I think this
>> could also cause confusion to implementers.
>>
>> Under section 5.2.2.1. “Redirect to Web Error Response” the spec mentions
>>
>>    In this case, the client is expected to initiate a new OAuth
>>
>>    Authorization Code flow with PKCE according to [RFC6749] and
>>
>>    [RFC7636].
>>
>>    If the client expects the frequency of this error response to be
>>
>>    high, the client MAY include a PKCE ([RFC7636]) code_challenge in the
>>
>>    initial authorization challenge request.  This enables the
>>
>>    authorization server to essentially treat the authorization challenge
>>
>>    request as a PAR [RFC9126] request, and return the request_uri and
>>
>>    expires_in as defined by [RFC9126] in the error response.  The client
>>
>>    then uses the request_uri value to build an authorization request as
>>
>>    defined in [RFC9126] Section 4.
>>
>> I think it would be good to add some text to the spec mentioning the
>> possibility to use the auth_session in this new authorization request such
>> that the user can continue the login from where the user left off.
>> Something similar is mentioned in section 6.1. for step-up authentication.
>>
>>
>> I have some concerns with the authorization_challenge_endpoint being able
>> to act as the PAR endpoint. I understand the improved experience gained
>> here but this essentially creates two standard endpoints that can do
>> similar things. Instead it might be possible to use the auth_session to
>> maintain the complete context. However this could be overloading the
>> expectations of the auth_session.
>>
>> Under section 5.3.1. “Auth Session” spec mentions;
>>
>>    The auth_session value is completely opaque to the client, and as
>>
>>    such the authorization server MUST adequately protect the value from
>>
>>    inspection by the client, for example by using a random string or
>>
>>    using a JWE if the authorization server is not maintaining state on
>>
>>    the backend.
>>
>> I think the intention behind mandating to maintain the opaqueness is to
>> protect any sensitive information. Depending on the AS implementation it
>> could decide on using an auth_session value which is not opaque but also
>> does not contain any sensitive data. I think it would be better to
>> recommend that the AS uses adequate measures such as encryption in the
>> event they are using something other than an opaque value that contains
>> sensitive data. The current mandating will put an unnecessary burden on the
>> AS to encrypt and decrypt data if it doesn’t contain sensitive information.
>>
>> In the same section it mentions;
>>
>>   To mitigate the risk of session hijacking, the 'auth_session' MUST be
>>
>>    bound to the device, and the authorization server MUST reject an
>>
>>    'auth_session' if it is presented from a different device than the
>>
>>    one it was bound to.
>>
>> I completely agree on the need to mitigate the risk of session hijacking.
>> However, in the current text, although it's not directly mentioned here, it
>> will require the AS to have a proof of possession mechanism in place as
>> pointed in Section 9 "Security Considerations". This can be a major
>> barrier to implement this specification as the AS should also implement
>> another specification. There can be different ways the implementation can
>> solve this problem without needing proof of possession. For example if the
>> auth_session is only transmitted between the AS and the client then it will
>> be protected with TLS in transit and the client and AS can use independent
>> mechanisms to protect the auth_session at rest. Since this specification
>> applies only to first party applications the implementers will have full
>> control over how the client and the AS protects the data, and therefore can
>> make sure adequate protection is in place for the auth_session. Due to this
>> I think it is better to change wording from mandating to a recommendation.
>>
>> Regarding section “7. Resource Server Error Response” I am wondering
>> whether this section is required at all as this spec makes no addition to
>> RFC9470. I guess this section is there to provide clarity due to RFC9470
>> using the authorization endpoint in its text.
>>
>> Under section 9.5.1. DPoP: Demonstrating Proof-of-Possession it mentions
>> “… The authorization server MUST ensure that the same key is used in all
>> subsequent Authorization Challenge Requests, or in the eventual token
>> request…” I think it was meant to say “... Authorization Challenge
>> Requests, and in the eventual token request…”
>>
>> Best Regards,
>>
>> Janak Amarasena
>>
>> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>