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. 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>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
