Re: [Architecture] [IAM] PKCE based OAuth flow for Public Clients

[Johann Nallathamby]

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  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 
> wrote:
>
>>
>>
>> On Mon, Jul 30, 2018 at 9:48 AM Dileesha Rajapakse 
>> 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
> Architecture@wso2.org
> 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
*
Medium: *https://medium.com/@johann_nallathamby
*
Twitter: *@dj_nallaa*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OAuth clients based on a trusted CA

[Prabath Siriwardena]

On Tue, Aug 7, 2018 at 4:42 AM, Farasath Ahamed  wrote:

>
>
> On Tue, Aug 7, 2018 at 4:53 PM, Prabath Siriwardena 
> wrote:
>
>> Hi Sathya,
>>
>> Yes... it is an extension to [1]...
>>
>> In this approach, we are going to avoid registration of individual
>> microservices (as OAuth clients) even no thumbprints registered... we
>> identify each one as a valid client, if the CA is valid, and dynamically
>> create clients for them on the fly, when they request tokens...
>>
>
> So when we dynamically creates we are going map mulitiple client ids
> against the same SP?
>

Yes...

Thanks & regards,
-Prabath


>
>> Thanks & regards,
>> -Prabath
>>
>>
>> On Tue, Aug 7, 2018 at 2:52 AM, Sathya Bandara  wrote:
>>
>>> Hi,
>>>
>>> A similar concept is defined in 'OAuth 2.0 Mutual TLS Client
>>> Authentication' specification [1]. There it defines two distinct methods
>>> for certificate based client authentication.
>>>
>>> 1. PKI Mutual TLS OAuth Client Authentication
>>>
>>> Uses a subject distinguished name (DN) and validated certificate chain to 
>>> identify the client.
>>>
>>> 2. Self-Signed Certificate Mutual TLS OAuth Client Authentication
>>> Support client authentication using self-signed certificates.  Client
>>> registers needs to associate a self-signed X.509 certificate at the time of
>>> registering. The client is successfully authenticated, if the subject
>>> public key info of the certificate matches the subject public key info of
>>> one of the certificates configured or registered for that client.
>>>
>>>
>>> Currently in IS we support only self-signed certificate based
>>> authentication [2].
>>>
>>> In the first method, client needs to associate the CA certificate and
>>> need to provide the DN of the signed certificate at the time of client
>>> registration. During mutual TLS handshake, we only need to validate
>>> client's CA certificate. The client is successfully authenticated if the
>>> subject information in the certificate matches with the expected DN
>>> configured or registered for that particular client.
>>>
>>> [1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1
>>> [2] "[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0
>>> clients"
>>>
>>> Thanks,
>>> Sathya
>>>
>>> On Tue, Aug 7, 2018 at 10:50 AM, Prabath Siriwardena 
>>> wrote:
>>>
 I guess following scenario will be useful in a microservices
 deployment, when we need to secure service to service communication.

 Please find below the steps..

 1. We create a service provider provider, and associate a CA's
 certificate with it.
 2. Now we have multiple microservices, each with a signed certificate
 from the previous trusted CA.
 3. Each of those microservice will be able to talk to the /token
 endpoint of IS (or STS), authenticate with mTLS and get a token. The token
 request also carries an audience value (or implied in scope).
 4. IS treats, the thumbprint of the cert (preferably SVID, in a
 SPIFFE/Istio environment) as the client id, and the access token is issued
 against it (which can be a JWT as well).
 5. This new access token/JWT can be used for service to service
 authentication, within the same domain or cross domain.

 This helps to onboard all the microservices, carrying a key pair (as
 their workload identity) to an OAuth environment.

 WDYT..?

 Thanks & Regards,
 Prabath

 Twitter : @prabath
 LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

 Blog: http://blog.facilelogin.com
 Vlog: http://vlog.facilelogin.com



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Sathya Bandara
>>> Software Engineer
>>> WSO2 Inc. http://wso2.com
>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>>>
>>> <+94%2071%20411%205032>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Twitter : @prabath
>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>
>> Blog: http://blog.facilelogin.com
>> Vlog: http://vlog.facilelogin.com
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Farasath Ahamed
> Senior Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,

Re: [Architecture] OAuth clients based on a trusted CA

[Prabath Siriwardena]

Hi Sathya,

Yes... it is an extension to [1]...

In this approach, we are going to avoid registration of individual
microservices (as OAuth clients) even no thumbprints registered... we
identify each one as a valid client, if the CA is valid, and dynamically
create clients for them on the fly, when they request tokens...

Thanks & regards,
-Prabath

On Tue, Aug 7, 2018 at 2:52 AM, Sathya Bandara  wrote:

> Hi,
>
> A similar concept is defined in 'OAuth 2.0 Mutual TLS Client
> Authentication' specification [1]. There it defines two distinct methods
> for certificate based client authentication.
>
> 1. PKI Mutual TLS OAuth Client Authentication
>
> Uses a subject distinguished name (DN) and validated certificate chain to 
> identify the client.
>
> 2. Self-Signed Certificate Mutual TLS OAuth Client Authentication
> Support client authentication using self-signed certificates.  Client
> registers needs to associate a self-signed X.509 certificate at the time of
> registering. The client is successfully authenticated, if the subject
> public key info of the certificate matches the subject public key info of
> one of the certificates configured or registered for that client.
>
>
> Currently in IS we support only self-signed certificate based
> authentication [2].
>
> In the first method, client needs to associate the CA certificate and need
> to provide the DN of the signed certificate at the time of client
> registration. During mutual TLS handshake, we only need to validate
> client's CA certificate. The client is successfully authenticated if the
> subject information in the certificate matches with the expected DN
> configured or registered for that particular client.
>
> [1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1
> [2] "[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0
> clients"
>
> Thanks,
> Sathya
>
> On Tue, Aug 7, 2018 at 10:50 AM, Prabath Siriwardena 
> wrote:
>
>> I guess following scenario will be useful in a microservices deployment,
>> when we need to secure service to service communication.
>>
>> Please find below the steps..
>>
>> 1. We create a service provider provider, and associate a CA's
>> certificate with it.
>> 2. Now we have multiple microservices, each with a signed certificate
>> from the previous trusted CA.
>> 3. Each of those microservice will be able to talk to the /token endpoint
>> of IS (or STS), authenticate with mTLS and get a token. The token request
>> also carries an audience value (or implied in scope).
>> 4. IS treats, the thumbprint of the cert (preferably SVID, in a
>> SPIFFE/Istio environment) as the client id, and the access token is issued
>> against it (which can be a JWT as well).
>> 5. This new access token/JWT can be used for service to service
>> authentication, within the same domain or cross domain.
>>
>> This helps to onboard all the microservices, carrying a key pair (as
>> their workload identity) to an OAuth environment.
>>
>> WDYT..?
>>
>> Thanks & Regards,
>> Prabath
>>
>> Twitter : @prabath
>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>
>> Blog: http://blog.facilelogin.com
>> Vlog: http://vlog.facilelogin.com
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sathya Bandara
> Software Engineer
> WSO2 Inc. http://wso2.com
> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>
> <+94%2071%20411%205032>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Blog: http://blog.facilelogin.com
Vlog: http://vlog.facilelogin.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OAuth clients based on a trusted CA

[Sathya Bandara]

Hi,

A similar concept is defined in 'OAuth 2.0 Mutual TLS Client
Authentication' specification [1]. There it defines two distinct methods
for certificate based client authentication.

1. PKI Mutual TLS OAuth Client Authentication

Uses a subject distinguished name (DN) and validated certificate chain
to identify the client.

2. Self-Signed Certificate Mutual TLS OAuth Client Authentication
Support client authentication using self-signed certificates.  Client
registers needs to associate a self-signed X.509 certificate at the time of
registering. The client is successfully authenticated, if the subject
public key info of the certificate matches the subject public key info of
one of the certificates configured or registered for that client.


Currently in IS we support only self-signed certificate based
authentication [2].

In the first method, client needs to associate the CA certificate and need
to provide the DN of the signed certificate at the time of client
registration. During mutual TLS handshake, we only need to validate
client's CA certificate. The client is successfully authenticated if the
subject information in the certificate matches with the expected DN
configured or registered for that particular client.

[1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1
[2] "[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0
clients"

Thanks,
Sathya

On Tue, Aug 7, 2018 at 10:50 AM, Prabath Siriwardena 
wrote:

> I guess following scenario will be useful in a microservices deployment,
> when we need to secure service to service communication.
>
> Please find below the steps..
>
> 1. We create a service provider provider, and associate a CA's certificate
> with it.
> 2. Now we have multiple microservices, each with a signed certificate from
> the previous trusted CA.
> 3. Each of those microservice will be able to talk to the /token endpoint
> of IS (or STS), authenticate with mTLS and get a token. The token request
> also carries an audience value (or implied in scope).
> 4. IS treats, the thumbprint of the cert (preferably SVID, in a
> SPIFFE/Istio environment) as the client id, and the access token is issued
> against it (which can be a JWT as well).
> 5. This new access token/JWT can be used for service to service
> authentication, within the same domain or cross domain.
>
> This helps to onboard all the microservices, carrying a key pair (as their
> workload identity) to an OAuth environment.
>
> WDYT..?
>
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Blog: http://blog.facilelogin.com
> Vlog: http://vlog.facilelogin.com
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture