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

[Janak Amarasena <[e-mail]>]

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
>
>