Hi Dimuthu/Ishara, On Thu, Nov 17, 2016 at 2:40 PM, Dimuthu Leelarathne <[email protected]> wrote:
> 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. > Yes. In the OAuth2 access token response there is a field which specifies this. Although client can't request a specific profile (its generally a server policy), the profile that was used in the response is communicated to the client. > 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 ?. >> > I am proposing this as a token profile for OAuth2. Like "Bearer" is one profile this can be a new one. >> -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 > -- 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
