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?
> > 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
