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
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
