Hi Prabath, In addition to these tokens, AM has application tokens which are handled in a separate path. Unlike access tokens, they need to decryptable to original format since they need to be shown in a UI to the user.
What would be the best way to handle application tokens in this case? Is it okay to use one way hashing for access/refresh tokens and a two way encryption algorithm here for application tokens? Thanks Rajeev On Fri, Jul 26, 2013 at 7:07 PM, Prabath Siriwardena <[email protected]>wrote: > 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 > -- 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
