AFAIK tokens are stored only in one place.. Thanks & regards, -Prabath
On Fri, Jul 26, 2013 at 7:01 PM, Rajeev Sampath <[email protected]> wrote: > Hi Ratha, > > > On Fri, Jul 26, 2013 at 6:32 PM, Vijayaratha Vijayasingam <[email protected] > > wrote: > >> >> >> On 26 July 2013 17:50, Rajeev Sampath <[email protected]> wrote: >> >>> Hi Prabath, >>> >>> >>> On Fri, Jul 26, 2013 at 3:35 PM, Prabath Siriwardena >>> <[email protected]>wrote: >>> >>>> >>>> >>>> On Fri, Jul 26, 2013 at 3:24 PM, Prabath Siriwardena >>>> <[email protected]>wrote: >>>> >>>>> There three aspects.. >>>>> >>>>> 1. Protect the confidentiality of the token at rest (in storage) >>>>> 2. Protect the confidentiality of the token in transit. >>>>> 3. Protect the confidentiality of the token from the client. >>>>> >>>>> [2] is achieved through TLS. >>>>> >>>>> [3] this is the one which mentioned in the spec. This is needed if we >>>>> have to include certain information in to the token that should not be >>>>> visible to the client. >>>>> >>>>> Doing [3] is very costly. What client gets there is an encrypted >>>>> token. So - its the same encrypted token that it will send to access >>>>> resources. So - for each request we need to decrypt it. >>>>> >>>>> Also the issue in [3] is - if you store the encrypted token in the >>>>> database - somebody having access to the database - can take the encrypted >>>>> token and use it to access the API (he does not need to decrypt it). >>>>> >>>>> What I would suggest is this. >>>>> >>>>> In the access token we issues we have some information parts and a >>>>> secret part. >>>>> >>>>> Information part is something like domain name.. like wise. Secret >>>>> part is the randomly generated string. >>>>> >>>>> Access Token = INFORMATION_PART + SECRET_KEY >>>>> >>>>> This is what I suggest.. >>>>> >>>>> Access Token = Base64Encode(INFORMATION_PART + ":" + SECRET_KEY) >>>>> >>>>> Client will get the Access Token and we store *Hash(SECRET_KEY)* in >>>>> the database (no encryption) >>>>> >>>> >>>> >>>> Correction --> we store *Hash(Access Token)* >>>> >>>> >>>>> >>>>> Now - when accessing the API client will send the Access Token >>>>> >>>>> Decoded Access Token = Base64Decode(Access Token) >>>>> = INFORMATION_PART + ":" + >>>>> SECRET_KEY >>>>> >>>>> Now to validate the token we check, *Hash(SECRET_KEY{from request}) = >>>>> **Hashed Secret Key from database* >>>>> >>>> >>>> Correction --> *Hash(Access Token{from request}) = **Hashed Access >>>> Token from database* >>>> * >>>> * >>>> >>> >>> In addition to these at IS level, access tokens are stored in AM as >>> well. So IMO for those, we'll have to use a symmetric algorithm that can >>> also decrypt and get the original key from an encrypted key. >>> >>> >> Why do we need decryption if we use hashing? And where will we need the >> original key, if we issue the encoded token to client? >> >> >>> >>> > My concern was on a scenario where AM having to use a stored token in non > hashed form (such as sending it to OAuth). In that case, OAuth will be > expecting an encoded but not hashed key (which I referred to as original > key here). So if the keys can't be converted back to the original state at > AM level won't that be a problem? > Or else won't there be such scenarios? > > > Thanks > Rajeev > > > >> Thanks >>> Rajeev >>> >>> >>> >>>> ** >>>> Thanks & regards, >>>> -Prabath >>>> * >>>> * >>>> >>>>> >>>>> This way we do not want to worry about encryption - and we also do not >>>>> store access token in clear text in the database. >>>>> >>>>> Refresh token can be just stored as a hash. >>>>> >>>>> Thanks & regards, >>>>> -Prabath >>>>> >>>>> On Fri, Jul 26, 2013 at 2:59 PM, Sumedha Rubasinghe >>>>> <[email protected]>wrote: >>>>> >>>>>> We need to attend to $subject. >>>>>> >>>>>> OAuth2 spec also recommends this in it's Threat Mitigation section. >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.2 >>>>>> "For those cases where the client is prevented from observing the >>>>>> contents of the token, token encryption MUST be applied in addition to >>>>>> the >>>>>> usage of TLS protection." >>>>>> >>>>>> Some design considerations. >>>>>> 1. Should be configurable (default off), configured via identity.xml >>>>>> 2. Need to consider token validation flow as well (hash should be >>>>>> generated of incoming token & compared) >>>>>> 3. Should we also store encrypting algorithm as well? (for backward >>>>>> compatibility if it changes after sometime) - Is this a real scenario? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> /sumedha >>>>>> b : bit.ly/sumedha >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> Prabath >>>>> >>>>> Mobile : +94 71 809 6732 >>>>> >>>>> http://blog.facilelogin.com >>>>> http://RampartFAQ.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> Prabath >>>> >>>> Mobile : +94 71 809 6732 >>>> >>>> http://blog.facilelogin.com >>>> http://RampartFAQ.com >>>> >>> >>> >>> >>> -- >>> Rajeev Sampath >>> Senior Software Engineer >>> WSO2, Inc.; http://www.wso2.com. >>> >>> Mobile:* +94716265766 >>> * >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> -Ratha >> mobile: (+94)755906608 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Rajeev Sampath > Senior Software Engineer > WSO2, Inc.; http://www.wso2.com. > > Mobile:* +94716265766 > * > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
