@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. Also we need to think about scenario where we have external key management servers plugged in. 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/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
