Please note that this solution only addresses 1 and 2. Not 3. I don't see addressing 3 is quite needed in our case.
Thanks & regards, -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* > * > * > 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 > -- 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
