Hi Johan, Do we need to implement this as additional security for Oauth. Instead shall we implement this as a different authentication mechanism that we support ?.
-Ishara On Wed, Nov 16, 2016 at 2:37 PM, Johann Nallathamby <[email protected]> wrote: > > > On Wed, Nov 16, 2016 at 2:26 PM, Sanjeewa Malalgoda <[email protected]> > wrote: > >> @Johan >> >> On Wed, Nov 16, 2016 at 4:13 AM, Johann Nallathamby <[email protected]> >> wrote: >> >>> Hi Nuwan/Sanjeewa, >>> >>> >>> On Wed, Nov 9, 2016 at 9:51 AM, Sanjeewa Malalgoda <[email protected]> >>> wrote: >>> >>>> Hi Johan, >>>> In that HOTP solution are we sending both bearer token and HOTP from >>>> client side? How this counter update should work if validation information >>>> cached and introspection call do not happen always? >>>> And other question is isn't that same as having shorter lifespan token >>>> with long live refresh token? >>>> >>> >>> Yes, making the lifetime of the token smaller and smaller reduces the >>> window of risk. But doesn't completely eliminate it. >>> >>> In the generic model I proposed, I didn't consider caching. I considered >>> each time the resource server (gateway) will talk to authz server (key >>> manager) by sending the (access token + hotp +counter value) and check for >>> the validity. >>> >>> If we need to do it with caching in the gateway I would suggest to >>> slightly change the model as follows. >>> 1. Have a service in in key manager to get client secret when access >>> token is given. >>> 2. For the very first validation of the token the gateway would talk to >>> the key manager with the access token and get the client secret, cache the >>> client secret and do the token validation. >>> >> Isn't this violate Oauth 2.0.0 introspection specification? As i remember >> introspection API will return only client id and not secret. >> > > Yes. Here we can't use introspection. It's a custom service I am > proposing. Reason being, recently there was another user, who was concerned > about bearer token security and for them we proposed to use client > certificate authentication for each API client. The disadvantage of that > approach is, the client has to manage certificates, expiry, etc. That is > also a custom solution. But compared to that I think in this solution there > is less work on the client side. > > Also we need to think about scenario where we have external key management >> servers plugged in. >> > > Yes. This is a special solution for those who use our Gateway and Key > Manager only. > > >> >> Thanks, >> sanjeewa. >> >> >>> 3. From the second time onwards the gateway can use the cached client >>> secret for the calculation. >>> >>> Of course we need to assess if there are any security issues in caching >>> the client secret in gateway. I am thinking as long as gateway doesn't have >>> direct DB access to the client credentials it should be fine. And also we >>> anyway cache the access token currently. So, given that the user is aware >>> of the security concerns we can go for the solution with caching even. >>> >>> >>>> >>>> Thanks, >>>> sanjeewa. >>>> >>>> On Tue, Nov 8, 2016 at 12:26 PM, Nuwan Dias <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Nov 3, 2016 at 11:58 AM, Johann Nallathamby <[email protected]> >>>>> wrote: >>>>> >>>>>> Recently have been seeing many users who are concerned about bearer >>>>>> token security in OAuth2. Although OAuth2 mandates to use TLS between the >>>>>> client and the resource server which makes it almost impossible to >>>>>> eavesdrop on the token while in transit, some people are still very >>>>>> sceptical about TLS, I guess due to rise in TLS related attacks in recent >>>>>> times. If an attacker somehow gets access to the access token then he can >>>>>> use it until it expires or is revoked. >>>>>> >>>>>> Just an idea that popped into my head is, what if we secure the APIs >>>>>> with bearer tokens + an HOTP for the client. In short HOTP works based >>>>>> on a >>>>>> shared secret and a counter value. The shared secret could be the client >>>>>> secret. The counter value would increment each time the access token is >>>>>> used to do an API call. >>>>>> >>>>> >>>>> +1 for the idea. >>>>> >>>>> Regarding the shared secret, we might need to think a bit on it >>>>> because the client secret is not available to clients using the implicit >>>>> grant AFAIK. So if we choose the client secret as the shared key, we may >>>>> not be able to use this token profile on the implicit grant. >>>>> >>>> >>> Yes. I am proposing this profile mainly for clients who care about >>> confidentiality of the tokens. The use of implicit grant type is mainly for >>> browser based applications which means they anyway don't have a way to >>> protect the access token. >>> >>> Regards, >>> Johann. >>> >>> >>>> >>>>>> If we define this as a new access token profile we can define it in a >>>>>> way that doesn't violate the OAuth2 framework specification because the >>>>>> access token profiles are extensible. >>>>>> >>>>>> Also MAC Token profile [1] tries to solve the same problem with >>>>>> bearer tokens. However, it depends on signing the payload. HOTP is >>>>>> payload >>>>>> independent. I think it may be advantageous in certain aspect like >>>>>> performance to choose HOTP over MAC Token profile. Also it has been in >>>>>> draft stage for too long without any updates, which could indicate its >>>>>> difficulty in implementing. >>>>>> >>>>>> There are upcoming specifications like [1], which try to bind the >>>>>> tokens to the TLS connection which they are intended to be used. They are >>>>>> still in early draft stage and I am not sure about the complexity of >>>>>> implementation of those. >>>>>> >>>>>> Thoughts are welcome. >>>>>> >>>>>> [1] https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 >>>>>> [2] https://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 >>>>>> >>>>>> Thanks & Regards. >>>>>> >>>>>> -- >>>>>> >>>>>> *Johann Dilantha Nallathamby* >>>>>> Technical Lead & Product Lead of WSO2 Identity Server >>>>>> Governance Technologies Team >>>>>> WSO2, Inc. >>>>>> lean.enterprise.middleware >>>>>> >>>>>> Mobile - *+94777776950* >>>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nuwan Dias >>>>> >>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>> email : [email protected] >>>>> Phone : +94 777 775 729 >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Sanjeewa Malalgoda* >>>> WSO2 Inc. >>>> Mobile : +94713068779 >>>> >>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>> :http://sanjeewamalalgoda.blogspot.com/ >>>> <http://sanjeewamalalgoda.blogspot.com/> >>>> >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Johann Dilantha Nallathamby* >>> Technical Lead & Product Lead of WSO2 Identity Server >>> Governance Technologies Team >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777776950* >>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>> >> >> >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Technical Lead & Product Lead of WSO2 Identity Server > Governance Technologies Team > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+94777776950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > -- Ishara Karunarathna Associate Technical Lead WSO2 Inc. - lean . enterprise . middleware | wso2.com email: [email protected], blog: isharaaruna.blogspot.com, mobile: +94717996791
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
