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 -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
