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