Hi All, In the OAuth handshake, do we also communicate about the access token profile? In that case it can be one of the profiles we support.
thanks, Dimuthu On Wed, Nov 16, 2016 at 4:54 PM, Ishara Karunarathna <[email protected]> wrote: > 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 > > -- Dimuthu Leelarathne Director, Solutions Architecture WSO2, Inc. (http://wso2.com) email: [email protected] Mobile: +94773661935 Blog: http://muthulee.blogspot.com Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
