Hi Dileesha, Why haven't we thought about breaking this further down as "Native" and "Single Page Applications". That is how some of the other implementations are breaking it down. Is it a conscious decision we've made after research?
What about the grant types? IMO client_credentials has to be disabled for SPAs. But for native mobile apps it might not have to be the case. Hence why I think we have to break it down further. Same with password and refresh_token grant types. We can disable them for SPAs. But for native apps they can be enabled after a warning message and confirmation from user. How about other custom grant types? Regards, Johann. On Fri, Aug 3, 2018 at 8:10 PM Dileesha Rajapakse <[email protected]> wrote: > Hi Hasintha, > > +1 for the input. I also agree with not making PKCE mandatory for all > public clients. Instead, we can advice people to use PKCE whenever they > want to use a public client in the documentation. > > Regards. > > On Mon, Jul 30, 2018 at 10:08 AM Hasintha Indrajee <[email protected]> > wrote: > >> >> >> On Mon, Jul 30, 2018 at 9:48 AM Dileesha Rajapakse <[email protected]> >> wrote: >> >>> Hi everyone, >>> >>> In the PKCE [1] enabled OAuth flow of the current implementation of the >>> IS, both client ID, and client secret are sent in the token request. >>> Ideally, according to the specification [2], public clients such as native >>> mobile and desktop applications should have the ability to acquire tokens >>> without sending a client secret since such clients are considered to be >>> unable to keep the client secret securely. To be able to support such a >>> scenario, an option to create an OAuth inbound application with Public >>> Client support was implemented and the following image depicts the added >>> functionality to the dashboard of the IS. Related development branches can >>> be found on [3] and [4]. >>> >>> [image: Screen Shot 2018-07-26 at 4.52.45 PM.png] >>> >>> Once enabled, public clients can acquire tokens without a client secret. >>> However, there are several points to be discussed regarding the >>> aforementioned flow. >>> >>> According to the specification on OAuth 2.0 for native apps [2], it is a >>> MUST for native clients to adhere to the PKCE standard. To enforce this, we >>> can make PKCE mandatory once the public client option is enabled. However, >>> even though that is the case for native applications, there can be >>> instances in which the user needs to implement a public client which does >>> not follow the PKCE standard. In such a situation, making PKCE mandatory >>> would be problematic. WDYT about this? >>> >> >> From authentication layer we can bypass the request if the client is >> public and a valid client. Making the app PKCE mandatory or not can be >> decided at a different level through a configuration as of now (AFAIK). >> For an example there can be two public clients, where one is used for >> native apps and the other is for non native apps. In that case the client >> which is used for native apps can be marked as PKCE mandatory by >> configuration (This is an extra step than making the app public). For the >> other public client still the PKCE might not be mandatory since we haven't >> enabled particular config. Having proper documentation would help people to >> understand that they should mark app as PKCE mandatory if the app is for >> native clients. >> >> IMO we don't need to make PKCE mandatory for public clients if the specs >> related to public clients does not enforce it . (Not the native client >> specs.) >> >>> >>> [1] - https://tools.ietf.org/html/rfc8252 >>> [2] - https://tools.ietf.org/html/rfc7636 >>> [3] - >>> https://github.com/dilee/identity-inbound-auth-oauth/tree/feature-oauth-public-client >>> [4] - >>> https://github.com/dilee/carbon-identity-framework/tree/feature-oauth-public-client >>> >>> Regards. >>> -- >>> *Dileesha Rajapakse* >>> Software Engineer | WSO2 Inc. >>> Mobile: +94 72555933 >>> http://www.dilee.me >>> >> >> >> -- >> Hasintha Indrajee >> WSO2, Inc. >> Mobile:+94 771892453 >> >> > > -- > *Dileesha Rajapakse* > Software Engineer | WSO2 Inc. > Mobile: +94 72555933 > http://www.dilee.me > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile: *+94 77 7776950* LinkedIn: *http://www.linkedin.com/in/johann-nallathamby <http://www.linkedin.com/in/johann-nallathamby>* Medium: *https://medium.com/@johann_nallathamby <https://medium.com/@johann_nallathamby>* Twitter: *@dj_nallaa*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
