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 <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
